Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-131

Text File | 1996-01-11 | 145.2 KB | 3,432 lines | [TEXT/R*ch]

C.S.M.P. Digest             Thu, 11 Jan 96       Volume 3 : Issue 131

Today's Topics:

        (Safely) Drawing directly to VRAM
        ANSWER: Get dirID from FSSpec
        Animation Libraries
        Changing the size of balloon help
        Need to unlock MF Temp Memory?
        New Mac games programming web site!
        Script Editor Apple Events
        [ANN] Mops 2.7 Macintosh Programming Environment



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is ftp://ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Eric A. Drumbor)
Subject: (Safely) Drawing directly to VRAM
Date: Wed, 06 Dec 1995 20:16:30 -0700
Organization: BW Software

     Yes, I know that this has been discussed before, but I'm going to dig
it up again :-)

     I *must* copy directly to the screen.  My frame updates/changes are
too small and too spread out to use CopyBits.  In other words, by using
CopyBits I'm probably copying about 20% - 50% more pixels than I really
need to move (if I use a single Rect or a series of Rects), besides the
fact that the overhead alone when making a few hundred copies per frame
would crush my presently decent frame rate.  So.....I made a simple delta
copying function (albeit somewhat crappy), and I'm writing directly to the
video memory.

     What are the odds this puppy will crash?  I see more of the
mainstream games using this method, and I assume that these games aren't
using CopyBits to copy two pixels on a scanline, then do the same for a
few hundred more scanlines.  The overhead for something like this would be
outrageous, so they *must* be writing to the video ram.

     How are these companies staying compatable with all the different
Macs and video configs?  Is there some kind of magic function to prevent
disaster when trying to write to the video memory of a video card? I've
been obtaining the base address of the screen via a few QD calls, finally
getting the base address from a PixMap handle.  So far this has worked,
but I'm afraid that later on down the road this will crash and burn
horribly.  What can I do to stay compatable while avoiding CopyBits?

--
"Once in a while, a notty little boy loses it and comes after Santa"
Eric A. Drumbor
[e-mail]                 <http://www.nilenet.com/~ericd/>
BW Software

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 7 Dec 1995 21:54:19 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] (Eric A. Drumbor) writes:
>horribly.  What can I do to stay compatable while avoiding CopyBits?

Read http://www.hut.fi/~jmunkki/misc/direct_mac_screen_access.txt

--
Juri Munkki [e-mail]      In cyberspace everyone can hear you scream.
http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Sun, 10 Dec 1995 04:43:41 -0800
Organization: ErsteSoft

In article <[e-mail]>,
[e-mail] (Eric A. Drumbor) wrote:

>      Yes, I know that this has been discussed before, but I'm going to dig
> it up again :-)
>
>      I *must* copy directly to the screen.>

No you don't. You can use CopyBits.

> My frame updates/changes are
> too small and too spread out to use CopyBits.

If that's true, then updating the screen is not your bottleneck. "Small
and spread out" means you aren't updating very many pixels.

> In other words, by using
> CopyBits I'm probably copying about 20% - 50% more pixels than I really
> need to move (if I use a single Rect or a series of Rects), besides the
> fact that the overhead alone when making a few hundred copies per frame
> would crush my presently decent frame rate.  So.....I made a simple delta
> copying function (albeit somewhat crappy), and I'm writing directly to the
> video memory.
>
>      What are the odds this puppy will crash?

100%. Guaranteed. Sorry to sound so pessimistic, but some of us still have
the battle scars from ignoring Apple's advice not to write directly to the
screen. It's good advice. Heed it.

Video memory will not always be memory mapped. Even if it is, it will not
always be writable. As memory protection improves (as it must if Apple
wants to make these machines more robust), VRAM won't always be in your
process' address space, even if it remains in the machine's address space.

> I see more of the
> mainstream games using this method, and I assume that these games aren't
> using CopyBits to copy two pixels on a scanline, then do the same for a
> few hundred more scanlines.  The overhead for something like this would be
> outrageous, so they *must* be writing to the video ram.

How are you "seeing" games use this method. Did you disassemble the code,
or trace it? If you had, you would *know* whether they were using
CopyBits, without having to make assumptions.

>      How are these companies staying compatable with all the different
> Macs and video configs?

CopyBits will always be able to write to the screen, even when the day
comes that you can't.

> Is there some kind of magic function to prevent
> disaster when trying to write to the video memory of a video card?

Yes. It's called CopyBits.

> I've
> been obtaining the base address of the screen via a few QD calls, finally
> getting the base address from a PixMap handle.  So far this has worked,
> but I'm afraid that later on down the road this will crash and burn
> horribly.  What can I do to stay compatable while avoiding CopyBits?

You can't. Nor do you have to. CopyBits is not really that slow.

In fact, I once wrote a benchmark where I put CopyBits head-to-head
against a handcrafted assembler routine to copy a full screen image
directly to the screen of a Mac Plus. The assembler routine used a
sequence of 32 MOVE.L (A0)+,(A1)+ instructions to copy each pair of
scanlines (32 x 32 = 1024 = 2 * 512), in a loop that repeated 171 times.
You can't get much tighter than that. But you know what? CopyBits beat it!
It turns out that, on a Mac Plus at least, CopyBits really is unbeatable.

Now I'm not claiming on the basis of that experiment that CopyBits is
always unbeatable. Far from it. This is a trick result. It turns out that
on a Plus, ROM is faster than RAM because it doesn't have to compete with
video refresh. Consequently, code in ROM (like CopyBits) has a slight edge
(about 20%) over code in RAM (like my assembler routine). The Plus also
does not support Color QuickDraw, so the CopyBits on that machine doesn't
have to mess with Palettes and ColorTables and all that sort of stuff.

But I do want you to notice two key points, that are relevant beyond the
Mac Plus:

a) Sure, CopyBits had a 20% advantage in code access, but it had no advantage
   in data accesses, it is much more general-purpose, yet despite all that it
   still beat my code by several percent. It did not fritter away its
   advantage through inefficiency.

b) CopyBits, being in ROM, can be tailored specifically for the machine it's
   running on. It will run on a 68000, it will use 68020 instructions on an
   '020, it runs native on a PowerMac. Because each ROM is specific to the
   machine it's installed in, ROM routines like CopyBits can safely do
   optimizations that you don't dare attempt, unless you're willing to ship
   your product with a dozen hand-tailored routines, each optimized for a
   different machine, including machines that haven't even been designed yet.
   Quite an undertaking.

Apple is fully aware of the importance of CopyBits. You can be sure that
on any machine they write the ROM for, CopyBits and BlockMove will be
optimized for that machine to within an inch of their lives.

You can help, though. When you call CopyBits, make sure the rectangles are
aligned to nice machine boundaries. In B/W, this means you widen the
rectangles if necessary so the left and right edges are longword aligned.
Even though this means you'll be copying more pixels, it'll actually be
faster because CopyBits won't have to do any masking. On an '040, give
CopyBits the opportunity to use a MOVE16 instruction. On a PowerMac, align
the rectangle boundaries to double-words, matching the width of the data
bus. (You can ignore cache row boundaries, since video is never cached.
Caching video would slow the machine to a crawl.)

Your best bet is to draw to an offscreen buffer (a GWorld), which you
conceptually divide into a number of nicely aligned rectangles. Keep track
of which rectangles are "dirty". (If you change any pixel in a rectangle,
the whole thing is dirty.) Then use CopyBits to copy the dirty rectangles
to the screen. Coalesce adjacent dirty rectangles when you can, to reduce
the number of calls. Make sure the source and destination have the same
ColorTable, so CopyBits can know that it doesn't have to translate color
indexes.

If your game draws into a movable window that is smaller than the screen
(always a nice courtesy), make sure the window remains aligned to nice
boundaries. If the user drags the window, snap it to a nice boundary.
HyperCard does this, for example. This guarantees that CopyBits won't have
to shift the data while it moves it. Alternatively, make the GWorld a
little bigger than the window, so you can shift the window contents in the
GWorld to align them with the window contents on the screen.

-Ron Hunsinger

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 10 Dec 1995 21:13:24 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Ron Hunsinger <[e-mail]> wrote:

>If that's true, then updating the screen is not your bottleneck. "Small
>and spread out" means you aren't updating very many pixels.

Yes, he isn't, and that's precisely why CopyBits is slow for him.
Overall, I agree with you, and I would recommend using CopyBits
whenever possible. It is true that CopyBits can't be beat for large
screen areas, as your test on a MacPlus shows; however, it can be beat
for small amounts of data, because it spends a relatively long time
setting things up before actually starting to copy. I'm no blitting
specialist, but I would recommend reading a Develop article on
CopyBits and its performance (sorry, I don't remember the issue
number).

--
Francois
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Sun, 10 Dec 1995 22:59:11 -0800
Organization: ErsteSoft

In article <4afihk$[e-mail]>, [e-mail] (Francois
Pottier) wrote:

> In article <[e-mail]>,
> Ron Hunsinger <[e-mail]> wrote:
>
> >If that's true, then updating the screen is not your bottleneck. "Small
> >and spread out" means you aren't updating very many pixels.
>
> Yes, he isn't, and that's precisely why CopyBits is slow for him.
> Overall, I agree with you, and I would recommend using CopyBits
> whenever possible. It is true that CopyBits can't be beat for large
> screen areas, as your test on a MacPlus shows; however, it can be beat
> for small amounts of data, because it spends a relatively long time
> setting things up before actually starting to copy. I'm no blitting
> specialist, but I would recommend reading a Develop article on
> CopyBits and its performance (sorry, I don't remember the issue
> number).

On small areas, the speed of CopyBits *per pixel* may be low, but if he
isn't updating very many pixels it doesn't matter. The total time spent
updating the screen, whether with CopyBits or otherwise, should remain
small.

-Ron Hunsinger

+++++++++++++++++++++++++++

>From [e-mail] (Christer Ericson)
Date: Mon, 11 Dec 1995 12:57:41 GMT
Organization: Dept. of Computing Science, Umea Univ., 901 87 Umea, Sweden

In <[e-mail]> [e-mail] (Ron Hunsinger) writes:
>[...]
>In fact, I once wrote a benchmark where I put CopyBits head-to-head
>against a handcrafted assembler routine to copy a full screen image
>directly to the screen of a Mac Plus. The assembler routine used a
>sequence of 32 MOVE.L (A0)+,(A1)+ instructions to copy each pair of
>scanlines (32 x 32 = 1024 = 2 * 512), in a loop that repeated 171 times.
>You can't get much tighter than that. But you know what? CopyBits beat it!
>It turns out that, on a Mac Plus at least, CopyBits really is unbeatable.
>
>Now I'm not claiming on the basis of that experiment that CopyBits is
>always unbeatable. Far from it. This is a trick result. It turns out that
>on a Plus, ROM is faster than RAM because it doesn't have to compete with
>video refresh. Consequently, code in ROM (like CopyBits) has a slight edge
>(about 20%) over code in RAM (like my assembler routine). The Plus also
>does not support Color QuickDraw, so the CopyBits on that machine doesn't
>have to mess with Palettes and ColorTables and all that sort of stuff.
>[...]

Another reason for your routine to come out slower than copybits is that
your code was not very well optimized. You should have used MOVEM with as
many registers as possible.

Of course, that's another point in favor of using copybits: if you're
not a really good programmer, chances are that your "optimized" blitter
will be less optimized than CopyBits.


Christer Ericson <This space for hire!> http://www.cs.umu.se/~christer/
phone: [phone], fax: [phone], email: [e-mail]
Department of Computing Science, Umea University, S-901 87 UMEA, SWEDEN

+++++++++++++++++++++++++++

>From [e-mail] (Mark Elliott)
Date: 11 Dec 1995 18:24:01 GMT
Organization: Max-Planck-Institut f. Kohlenforsch. Muelheim

In article <[e-mail]>,
[e-mail] (Ron Hunsinger) wrote:

> In article <[e-mail]>,
> [e-mail] (Eric A. Drumbor) wrote:
>
> >      Yes, I know that this has been discussed before, but I'm going to dig
> > it up again :-)
> >
> >      I *must* copy directly to the screen.>
>
> No you don't. You can use CopyBits.

Oh come on Ron. Apple have published guidelines for direct-to-screen drawing.

For a game I am writing there is simply no way I could get acceptable
frame rates using copybits. Even drawing directly into vram was a push.
Now, a game which would have required a 68040 as minimum will run happily
on a 25 MHz 68030. This has to be a consideration.

Direct to screen drawing is not dangerous. Yeah, I am sure that some
hardware configurations (eg. strange graphics accelerators) MIGHT cause
problems. However, after the initial teething troubles (which are
certainly not unique to vram access) I have had essentially NO crashes. I
have tested my game on a wide range of 68K and powerpc macs with a fair
selection of monitor sizes.

> > My frame updates/changes are
> > too small and too spread out to use CopyBits.
>
> If that's true, then updating the screen is not your bottleneck. "Small
> and spread out" means you aren't updating very many pixels.

And updating them using a single copybits is moving far too many bytes.
Sure you could keep track of which pixels are modified. I assume you are
creating your screen in a gworld and then copying to the screen. If you
keep track of which pixels are modified (or Rects around them) then only
CopyBits the parts which you need to, this might help. However, by the
sound of things, these will be small areas - this is where CopyBits
performs at its worst.

> > In other words, by using
> > CopyBits I'm probably copying about 20% - 50% more pixels than I really
> > need to move (if I use a single Rect or a series of Rects), besides the
> > fact that the overhead alone when making a few hundred copies per frame
> > would crush my presently decent frame rate.  So.....I made a simple delta
> > copying function (albeit somewhat crappy), and I'm writing directly to the
> > video memory.
> >
> >      What are the odds this puppy will crash?
>
> 100%. Guaranteed. Sorry to sound so pessimistic, but some of us still have
> the battle scars from ignoring Apple's advice not to write directly to the
> screen. It's good advice. Heed it.

If programmed properly it is no more likely to crash than any other program.

As I said, Apple have published guidelines for direct-to-screen drawing
(an issue of Develop. Eric, mail me and I will try to help you out with
references/code). They recommend that you don't do it, but at least they
tell you the safe way to do it.


> Video memory will not always be memory mapped. Even if it is, it will not
> always be writable. As memory protection improves (as it must if Apple
> wants to make these machines more robust), VRAM won't always be in your
> process' address space, even if it remains in the machine's address space.
>
> > I see more of the
> > mainstream games using this method, and I assume that these games aren't
> > using CopyBits to copy two pixels on a scanline, then do the same for a
> > few hundred more scanlines.  The overhead for something like this would be
> > outrageous, so they *must* be writing to the video ram.
>
> How are you "seeing" games use this method. Did you disassemble the code,
> or trace it? If you had, you would *know* whether they were using
> CopyBits, without having to make assumptions.

I have disassembled many action games. In almost all cases, games which
are highly rated (eg. the Ambrosia games) use direct to screen drawing. I
have yet to see one of these games crash.

> >      How are these companies staying compatable with all the different
> > Macs and video configs?
>
> CopyBits will always be able to write to the screen, even when the day
> comes that you can't.

They are using GetBaseAddr to find the address of screen memory. They
check the device list to find a screen which supports the required depth
and has the required size. They check the pixMap to find the rowBytes
value. Then they make sure that there is no way their drawing will be
outside of the screen memory.

> > Is there some kind of magic function to prevent
> > disaster when trying to write to the video memory of a video card?
>
> Yes. It's called CopyBits.

Sure this will prevent disaster, but it may also prevent acceptable performance.

>
> > I've
> > been obtaining the base address of the screen via a few QD calls, finally
> > getting the base address from a PixMap handle.  So far this has worked,
> > but I'm afraid that later on down the road this will crash and burn
> > horribly.  What can I do to stay compatable while avoiding CopyBits?
>
> You can't. Nor do you have to. CopyBits is not really that slow.

> In fact, I once wrote a benchmark where I put CopyBits head-to-head
> against a handcrafted assembler routine to copy a full screen image
> directly to the screen of a Mac Plus. The assembler routine used a
> sequence of 32 MOVE.L (A0)+,(A1)+ instructions to copy each pair of
> scanlines (32 x 32 = 1024 = 2 * 512), in a loop that repeated 171 times.
> You can't get much tighter than that. But you know what? CopyBits beat it!
> It turns out that, on a Mac Plus at least, CopyBits really is unbeatable.

I think I know what went wrong here. You unwrapped the loop. Yeah,
everyone says you should do this. It is usually faster. However if you
unwrap the loop to the extent that the loop is larger than the processors
cache, it will have to reload the code possibly several times per loop.

Also, copying large areas is where CopyBits wins. Try copying a 24 x 24
sprite using a custom blitter or using copybits. If you can get CopyBits
to perform at half the speed of your blitter you should write a better
blitter.

> Now I'm not claiming on the basis of that experiment that CopyBits is
> always unbeatable. Far from it. This is a trick result. It turns out that
> on a Plus, ROM is faster than RAM because it doesn't have to compete with
> video refresh. Consequently, code in ROM (like CopyBits) has a slight edge
> (about 20%) over code in RAM (like my assembler routine). The Plus also
> does not support Color QuickDraw, so the CopyBits on that machine doesn't
> have to mess with Palettes and ColorTables and all that sort of stuff.
>
> But I do want you to notice two key points, that are relevant beyond the
> Mac Plus:
>
> a) Sure, CopyBits had a 20% advantage in code access, but it had no advantage
>    in data accesses, it is much more general-purpose, yet despite all that it
>    still beat my code by several percent. It did not fritter away its
>    advantage through inefficiency.
>
> b) CopyBits, being in ROM, can be tailored specifically for the machine it's
>    running on. It will run on a 68000, it will use 68020 instructions on an
>    '020, it runs native on a PowerMac. Because each ROM is specific to the
>    machine it's installed in, ROM routines like CopyBits can safely do
>    optimizations that you don't dare attempt, unless you're willing to ship
>    your product with a dozen hand-tailored routines, each optimized for a
>    different machine, including machines that haven't even been designed yet.
>    Quite an undertaking.
>
> Apple is fully aware of the importance of CopyBits. You can be sure that
> on any machine they write the ROM for, CopyBits and BlockMove will be
> optimized for that machine to within an inch of their lives.

As optimised as a very general routine can be.

> You can help, though. When you call CopyBits, make sure the rectangles are
> aligned to nice machine boundaries. In B/W, this means you widen the
> rectangles if necessary so the left and right edges are longword aligned.
> Even though this means you'll be copying more pixels, it'll actually be
> faster because CopyBits won't have to do any masking. On an '040, give
> CopyBits the opportunity to use a MOVE16 instruction. On a PowerMac, align
> the rectangle boundaries to double-words, matching the width of the data
> bus. (You can ignore cache row boundaries, since video is never cached.
> Caching video would slow the machine to a crawl.)
>
> Your best bet is to draw to an offscreen buffer (a GWorld), which you
> conceptually divide into a number of nicely aligned rectangles. Keep track
> of which rectangles are "dirty". (If you change any pixel in a rectangle,
> the whole thing is dirty.) Then use CopyBits to copy the dirty rectangles
> to the screen. Coalesce adjacent dirty rectangles when you can, to reduce
> the number of calls. Make sure the source and destination have the same
> ColorTable, so CopyBits can know that it doesn't have to translate color
> indexes.

This is a very good suggestion.

> If your game draws into a movable window that is smaller than the screen
> (always a nice courtesy), make sure the window remains aligned to nice
> boundaries. If the user drags the window, snap it to a nice boundary.
> HyperCard does this, for example. This guarantees that CopyBits won't have
> to shift the data while it moves it. Alternatively, make the GWorld a
> little bigger than the window, so you can shift the window contents in the
> GWorld to align them with the window contents on the screen.


Okay, very good advice about CopyBits, but what about the situations where
CopyBits is not fast enough. Direct to screen drawing can be much faster.
For a sprite game (which is what I am writing) you generally know what
sort of movement your sprites will have, and how best to handle them.
Depending on your game, there are a huge number of optimisations you can
make.

For instance, it is possible to erase a sprite while redrawing the next
frame, all directly to the screen (i.e. no drawing into gworlds first) in
a single step, and using only 3 68K assembly language instructions for 4
pixels PROVIDED certain conditions are met. I do this and have noticed no
flicker.

With the blitters I am using, I could (read CAN) do all my drawing in a
single vbl interrupt on anything above a 25MHz 040. Since an 030 will not
(quite) manage this, I prefer not to.


What to avoid ? Writing outside of video ram. This may sound obvious, but
make sure your routines do not slip outside vram. This will almost always
cause a bus error (crash!!!). Also you will need to run in only one screen
depth (most people go for 8-bit). You should ensure that the chosen
graphics device supports this depth and is actually set to it.
If you allow users access to the menu bar during your game loop, you will
have to ensure that someone hasn't used color switch to change depth. Many
games don't allow access to the menu bar (except when the game is paused),
so you might not have this worry.

At the very least you should check after every resume event that the
screen depth has not changed. If the screen depth has changed (or in fact
is not suitable when the game starts) you should either just change it
(some people won't like that), and then change back on a suspend event, or
tell the user to change it/give them the option. How you handle this is
really up to you.

Anyway, I hope this helps. I would say that you should think very
carefully before drawing direct to the screen. You should try to use
copybits in a more intellingent way (like only updating the areas you
really need to). You should make sure all copying areas are longword
aligned. You should make sure the source and destination are the same
depth/same color table. If none of this helps you get the performance you
need, you should then try direct to screen drawing for some of your
'safer' copies and make sure it helps (running a profiler will help you
out here). No sense having all the headache of vram access if that isn't
the bottleneck. If it helps, then you will probably want to change all
your code to direct screen.

You will probably find you have a large number of blitters for each sprite
size - no sense writing a too general routine. Personally I have a pointer
to my blitter as part of a sprite's data structure. There are a number of
occasions where I want to change the blitter. I have found this to be
easiest.


Don't ignore Ron's advice completely, but I would say it is a bit extreme.
Just be careful.

And feel free to email me if you need help.

Mark

- ------------------------------------------------------------------
Mark C Elliott                           [e-mail]
Max-Planck-Institut                      voice: ([phone]
Fuer Kohlenforschung
Muelheim, Germany
- ------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Adam Miller)
Date: 11 Dec 1995 18:48:23 GMT
Organization: Yale University

In article <[e-mail]>
[e-mail] (Ron Hunsinger) writes:

> On small areas, the speed of CopyBits *per pixel* may be low, but if he
> isn't updating very many pixels it doesn't matter. The total time spent
> updating the screen, whether with CopyBits or otherwise, should remain
> small.

That can often be far from the case.  I wrote a game that typically had
about thirty generally 32x32 sprites running around the screen at any
given time.  CopyBits was slow, so I wrote a very simple blitter in C.
The result was a 3x speedup.  Copying the entire screen, not just the
update regions, with CopyBits was about as fast as using CopyBits for
the individual sprites.  The thing to remember is that video ram is
really slow, so you don't want to write more than necessary.

Anyway, the solution for the poster is to write a blitter, but give the
user the option to turn it off and use CopyBits.  That way you'll
achieve full speed on the 99% at least of Macs that will work with a
blitter, but you'll also retain compatibility.

adum

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Mon, 11 Dec 1995 17:05:59 -0500
Organization: Carnegie Mellon, Pittsburgh, PA

[e-mail] (Mark Elliott) writes:
> > No you don't. You can use CopyBits.
>
> Oh come on Ron. Apple have published guidelines for direct-to-screen drawing.
>
> For a game I am writing there is simply no way I could get acceptable
> frame rates using copybits. Even drawing directly into vram was a push.
> Now, a game which would have required a 68040 as minimum will run happily
> on a 25 MHz 68030. This has to be a consideration.

And you have a "quickdraw-compatible" mode, right?  Which uses
CopyBits? For people with that strange hardware configuration you
*didn't* test?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Wed, 13 Dec 1995 08:09:41 -0800
Organization: ErsteSoft

In article <[e-mail]>,
[e-mail] (Mark Elliott) wrote:

> In article <[e-mail]>,
> [e-mail] (Ron Hunsinger) wrote:
>
> > In article <[e-mail]>,
> > [e-mail] (Eric A. Drumbor) wrote:
> >
> > >      I *must* copy directly to the screen.>
> >
> > No you don't. You can use CopyBits.
>
> Oh come on Ron. Apple have published guidelines for direct-to-screen drawing.

The only published guidelines I have seen from Apple is "don't do it".

> Direct to screen drawing is not dangerous. Yeah, I am sure that some
> hardware configurations (eg. strange graphics accelerators) MIGHT cause
> problems. However, after the initial teething troubles (which are
> certainly not unique to vram access) I have had essentially NO crashes. I
> have tested my game on a wide range of 68K and powerpc macs with a fair
> selection of monitor sizes.

Change MIGHT to WILL.

Have you tested your games on the Macs that will be coming out 5 years from now?

> And updating them using a single copybits is moving far too many bytes.
> Sure you could keep track of which pixels are modified. I assume you are
> creating your screen in a gworld and then copying to the screen. If you
> keep track of which pixels are modified (or Rects around them) then only
> CopyBits the parts which you need to, this might help. However, by the
> sound of things, these will be small areas - this is where CopyBits
> performs at its worst.

That is exactly what I recommended. I also recommended making sure the
rectangles are aligned to memory boundaries. It's when the rectangles are
unaligned that CopyBits is really slow.

It isn't just the number of pixels. Sometimes, copying more pixels is
actually faster than copying fewer.

> > >      What are the odds this puppy will crash?
> >
> > 100%. Guaranteed. Sorry to sound so pessimistic, but some of us still have
> > the battle scars from ignoring Apple's advice not to write directly to the
> > screen. It's good advice. Heed it.
>
> If programmed properly it is no more likely to crash than any other program.
>
> As I said, Apple have published guidelines for direct-to-screen drawing
> (an issue of Develop. Eric, mail me and I will try to help you out with
> references/code). They recommend that you don't do it, but at least they
> tell you the safe way to do it.

I think you're figuring the odds over too small a sample. If it works on a
particular machine, it will always work on that machine. But there are
machines where it won't work at all. For example:

  a) Any Macintosh running A/UX will protect the screen. Programs that
     try to write to the screen under A/UX will crash.

  b) The combination of 24-bit addressing mode and NuBus video will prevent
     writing to the screen, because the NuBus memory is out of reach of
     24-bit addresses. CopyBits knows to call SwapMMUMode at the right time.
     It's really hard for your code to do this in a portable way. It's even
     harder to anticipate the problem -- kudos if you had it implemented
     BEFORE the Mac II came out.

The fact that there are already two kinds of Macintosh that won't support
direct access to the screen should be a hint that there will be others.

As for trusting Apple because they told us how to do something, think
about how many other times they've told us "Don't do this, but if you do
here's how".

They told us:

   Don't modify the fields of a GrafPort directly, because they may change,
   but if you feel you must here's the layout. [CGrafPorts have a different
   layout.]

   Don't manipulate memory manager structures, but if you must here's what
   they look like. [Then along came 32-bit addressing, and all the MM
   structures changed, from the TZone record down to the link words before
   each field, and even the bits within a master pointer.]

   Don't play sounds by putting the data directly into the sound buffers,
   but if you must, here's how. [There aren't any sound buffers now.]

   Don't expect every machine to support page flipping, but here's how to
   do it. [No machine in recent history has supported page flipping.]

   There will be a single screen, 512x342 pixels, 1 bit per pixel. But for
   compatibility with future machines, it's safer to rely on screenBits.
   [screenBits is a BitMap, even if your main screen is in color.
   screenBits.rowBytes is a lie, on the grounds that this little lie
   breaks fewer programs than the truth would. And you know what happened
   to screen sizes, screen depths, and even the number of screens.]

   There will be a single menu bar at the top of the screen. It will be
   20 pixels high, and contain the names, in Chicago 12, of every menu.
   Menus will not pop up from other places, like from within windows, and
   most certainly not out of other menus. There won't be anything in the
   menu bar except menu names. No icons (unless you count the Apple as an
   icon, which it isn't). [Not a single word of the foregoing is still
   true, although I'm sure Apple meant it all at the time.]

If you really think it's different this time, when Apple says "Don't write
to the screen, but if you must here's how", go right ahead. I've learned
that when they say "Don't do this, but if you must here's how," they mean
"This may work now, but it's going to break, and probably sooner than you
expect."

> I have disassembled many action games. In almost all cases, games which
> are highly rated (eg. the Ambrosia games) use direct to screen drawing. I
> have yet to see one of these games crash.

They will. Not on the machines that they are running on (obviously). But
they won't run on the machines that will be on the market in five years.
Nor on a Mac II, at least not at first.

> > >      How are these companies staying compatable with all the different
> > > Macs and video configs?
> >
> > CopyBits will always be able to write to the screen, even when the day
> > comes that you can't.
>
> They are using GetBaseAddr to find the address of screen memory. They
> check the device list to find a screen which supports the required depth
> and has the required size. They check the pixMap to find the rowBytes
> value. Then they make sure that there is no way their drawing will be
> outside of the screen memory.

Getting the base address is nice. That's what we did on the early
machines. We didn't call it GetBaseAddr, of course. We called it
screenBits.baseAddress, and for all anyone knew at the time, that (and the
rest of screenBits) was all you needed to know. Ask anybody. They'd tell
you. That was how you did it, and it was perfectly safe.

Except for Apple, of course. Those wet blankets kept saying "Don't write
to the screen. Your program will crash on future Macs." But hey, what did
they know? And what's that you say about "device list", "pixMap", and all
that? We didn't worry about things like that, because things like that
hadn't been invented yet.

What things are you overlooking that haven't been invented yet?

> Sure this will prevent disaster, but it may also prevent acceptable
performance.

When the new machines come out, and your program won't even run, that's
REALLY unacceptable performance.

> I think I know what went wrong here. You unwrapped the loop. Yeah,
> everyone says you should do this. It is usually faster. However if you
> unwrap the loop to the extent that the loop is larger than the processors
> cache, it will have to reload the code possibly several times per loop.

Cache on a 68000? I was very explicit that the test was run on a Plus,
that it was optimized for a Plus, and that the results were only
meaningful on the Plus. The Plus has a 68000, which does not have a cache.
The more you unwind the loop, the better.

But you're correct about how traditional optimization techniques become
counterproductive as the hardware changes. Even on a 68010, a simple
MOVE.L (A0)+,(A1)+;DBRA D0,*-4 becomes unbeatable. The MOVE16 on the 68040
may be better yet, but only a little and only if your RAM supports burst
read/write.

The point is that the ROM on your machine knows what processor you have
AND it knows any other idiosynchrocies that your configuration may have.
Your code cannot afford to have separate code optimized for each possible
machine, so it has to compromise. The ROM doesn't.

> Also, copying large areas is where CopyBits wins. Try copying a 24 x 24
> sprite using a custom blitter or using copybits. If you can get CopyBits
> to perform at half the speed of your blitter you should write a better
> blitter.

By the time I call CopyBits, all the tricky parts will be done. That is, I
would write a custom blitter that does all the necessary shifting,
masking, erasing, maybe color translation if that's called for in the
game. Then I'd use CopyBits just to get the data to the screen. In a
sense, this makes the CopyBits time pure overhead. On the other hand,
CopyBits will be called only with the easiest parameters. Also, the
separation into two passes lets me process (possibly overlapping) sprites
back to front in the first pass, and non-overlapping rectangles top to
bottom in the second pass, so I don't need to worry about tearing or
flicker. There won't be any, even if I don't synch up to VBL, and even on
slow machines. The second pass, even if done with CopyBits, is a lot
simpler than the first pass. If it adds even 50% to your drawing time,
you're not drawing a very complex image.

> Okay, very good advice about CopyBits, but what about the situations where
> CopyBits is not fast enough. Direct to screen drawing can be much faster.
> For a sprite game (which is what I am writing) you generally know what
> sort of movement your sprites will have, and how best to handle them.
> Depending on your game, there are a huge number of optimisations you can
> make.

I accept that direct-to-screen may be a little faster, but I don't believe
that it's going to be a lot faster.

> You will probably find you have a large number of blitters for each sprite
> size - no sense writing a too general routine. Personally I have a pointer
> to my blitter as part of a sprite's data structure. There are a number of
> occasions where I want to change the blitter. I have found this to be
> easiest.

I like that. That's a good idea.

> Don't ignore Ron's advice completely, but I would say it is a bit extreme.
> Just be careful.

Ok, I'll leave it at that. We've both stated our opinions, and he can decide.

-Ron Hunsinger

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Wed, 13 Dec 1995 20:40:21 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Jason Regier) wrote:
> > > Direct to screen drawing is not dangerous. Yeah, I am sure that some
> > > hardware configurations (eg. strange graphics accelerators) MIGHT cause
> > > problems.
> > Change MIGHT to WILL.
> >
> Oh come on.  Many games have used, and will use, direct-to-screen blitting
> to get the performance they want/need.  To wit: Spaceway 2000, any
> Ambrosia Software game, Dark Forces (according to notes for their 1.2
> updater), Space Madness, etc.  These games aren't getting flamed right and
> left for their incompatibilities with existing machines.  If they were
> incompatible with a majority of the machines in the market, they wouldn't
> sell at all.  But as you suggest, as a precaution, some of them wisely
> allow a CopyBits-only mode just in case you're having problems with the
> direct-to-screen drawing.
>
> > Have you tested your games on the Macs that will be coming out 5 years
> from now?
> As callous as this might sound, I would venture to say that those
> commercial products using direct-to-screen writing (especially those not
> supporting a CopyBits mode) aren't totally worried about working 5 years
> from now.  5 years from now, their game will no longer be cutting edge,
> their profit margins will have fallen considerably and they most likely
> won't be on store shelves anymore.  It's a just a chance developers are
> willing to take in order to release a cutting-edge game now and make a
> profit in the current market.

As long as you follow the recommendations (those in _develop_ are
a pretty good summary), and in particular are careful to check that
your window really is in the front, is not obscured, be sure
to call ShieldCursor() before drawing, and have non-buggy blit loops,
you'll probably be safe drawing to the screen moving forward to the
future.

There is no way to promise 100% that everyone's (or anyone's) direct
to screen drawing will work forever.  However, within the above
mentioned guidelines, it is likely that your game will be OK
at least in the short->medium term.

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

>From [e-mail] (Jason Regier)
Date: Wed, 13 Dec 1995 11:25:09 -0800
Organization: Qualcomm, Inc.

In article <[e-mail]>,
[e-mail] (Ron Hunsinger) wrote:
> The only published guidelines I have seen from Apple is "don't do it".
>
Then check out Develop magazine, which is available online from Apple.  I
think it might be in issue 9, and the article is called something like
"Safely Drawing Directly to the Screen".  It tells you all the caveats,
and provides very readable (but not optimal) sample code for
direct-to-screen blitting.

> > Direct to screen drawing is not dangerous. Yeah, I am sure that some
> > hardware configurations (eg. strange graphics accelerators) MIGHT cause
> > problems.
> Change MIGHT to WILL.
>
Oh come on.  Many games have used, and will use, direct-to-screen blitting
to get the performance they want/need.  To wit: Spaceway 2000, any
Ambrosia Software game, Dark Forces (according to notes for their 1.2
updater), Space Madness, etc.  These games aren't getting flamed right and
left for their incompatibilities with existing machines.  If they were
incompatible with a majority of the machines in the market, they wouldn't
sell at all.  But as you suggest, as a precaution, some of them wisely
allow a CopyBits-only mode just in case you're having problems with the
direct-to-screen drawing.

> Have you tested your games on the Macs that will be coming out 5 years
from now?
As callous as this might sound, I would venture to say that those
commercial products using direct-to-screen writing (especially those not
supporting a CopyBits mode) aren't totally worried about working 5 years
from now.  5 years from now, their game will no longer be cutting edge,
their profit margins will have fallen considerably and they most likely
won't be on store shelves anymore.  It's a just a chance developers are
willing to take in order to release a cutting-edge game now and make a
profit in the current market.

> It isn't just the number of pixels. Sometimes, copying more pixels is
> actually faster than copying fewer.
>
If you've read the Develop article or Tricks of the Mac Game Programming
Gurus, you'll remember that CopyBits does extremely poorly when copying
tiny sprites.  If you're copying lots of tiny sprites to the screen, and
you can't beat the overhead incurred by CopyBits, you're probably doing
something wrong.

> The fact that there are already two kinds of Macintosh that won't support
> direct access to the screen should be a hint that there will be others.
>
This is a good point.  It doesn't mean you shouldn't allow this option in
your game, can't guarantee its success either.

As for things that Apple told you not to do, I wanted to point out a few things:
>    Don't play sounds by putting the data directly into the sound buffers,
>    but if you must, here's how. [There aren't any sound buffers now.]
>
SoundManager supports a bufferCmd, which is used as a parameter to
SoundDoCommand() or SoundDoImmediate().  If you wish, you can play sounds
directly this way instead of using SoundPlay.

>    Don't expect every machine to support page flipping, but here's how to
>    do it. [No machine in recent history has supported page flipping.]
>
Although I've never done it, some Macs actually had/have hardware support
for page flipping-- I believe it was called the Valkyrie chip.  I think
Juri Munkki might have supported this in Arashi, but he'll have to confirm
this.

The fact is, things change.  Apple's documentation isn't perfect, and it's
always changing.  You can't rely on old news, even if it's in print, to be
the current gospel.  Apple wrote years ago in Develop that
direct-to-screen drawing wasn't recommended and may be incompatible with
future software and hardware, but that it's sometimes necessary to get the
most out of high-powered programs, like games and graphics demos.  That
being said, you roll the dice, you take your chances.  And as I'm sure
many software developers can say, sometimes the payoffs for taking such
risks are big.

Jason

--
Jason Regier
GlobalStar Software Engineer
QUALCOMM, Inc.
[phone]
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 14 Dec 1995 04:37:34 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] (Ron Hunsinger) writes:
>The only published guidelines I have seen from Apple is "don't do it".

Then it's probably best if you don't do it and let us (who have seen
the guidelines) do it.

>Change MIGHT to WILL.
>Have you tested your games on the Macs that will be coming out 5 years from now?

I see screen buffer access changes the least of the reasons why games
software will break in five years.

Let's think of this: the Sound Driver is dead, gone, kaput. Does that mean
that back before the Sound Manager existed, we should have avoided using
sound (especially double buffered sampled sound, since Apple said the
support was going away) just because we knew it wasn't going to work in
the distant future. I don't think so...stuff like that is necessary when
you are writing games. Some day it will not work, but if you stay up to
date, you can release a free update of your program before anyone has
trouble with your code.

>  a) Any Macintosh running A/UX will protect the screen. Programs that
>     try to write to the screen under A/UX will crash.

Incorrect. Last time I checked, Arashi was still working fine on A/UX.
That was a while ago. A more recent example is a screen saver that I
wrote last year: it's used with DarkSide on an A/UX workgroup server.
Hasn't crashed so far and it doesn't use QuickDraw for drawing.

>  b) The combination of 24-bit addressing mode and NuBus video will prevent
>     writing to the screen, because the NuBus memory is out of reach of
>     24-bit addresses. CopyBits knows to call SwapMMUMode at the right time.
>     It's really hard for your code to do this in a portable way. It's even
>     harder to anticipate the problem -- kudos if you had it implemented
>     BEFORE the Mac II came out.

It breaks when you are not following the rules. There are two
approaches to SwapMMUMode: call it always (it doesn't hurt, since it is
documented to be a no-op on machines with 32-bit addressing) or check
the flag bit of the pixel map you are writing to.

Almost everyone missed this one back in the days of the Mac II. Actually
it seems to me that quite a few programmers learned about it from me. I
remember telling Ingemar Ragnemalm and John Calhoun. It's still the #1
mistake that games programmers make: look at Wolfenstein 3D (at least
the first version...I don't know if they fixed it).

>The fact that there are already two kinds of Macintosh that won't support
>direct access to the screen should be a hint that there will be others.

So, can anyone come up with a real case where it really isn't possible
to draw directly to the screen on a Mac? The closest I can think of is
Pivot software and Stepping Out, since you are actually fooled into
drawing into their buffers. It still copies back onto the screen later,
if you called ShieldCursor/ShowCursor.


>   Don't play sounds by putting the data directly into the sound buffers,
>   but if you must, here's how. [There aren't any sound buffers now.]

Well, as I said above, what they told us to do back then no longer works,
but that was expected.

>They will. Not on the machines that they are running on (obviously). But
>they won't run on the machines that will be on the market in five years.
>Nor on a Mac II, at least not at first.

Would you like to bet on it?

>I accept that direct-to-screen may be a little faster, but I don't believe
>that it's going to be a lot faster.

I guess how fast you can go depends on the programmer. A bad programmer can
do a lot worse than CopyBits. A good programmer will be able to do a lot better.

Even without dynamic sprite compiling, the 8-bit masked blitter that was
co-written on comp.sys.mac.programmer a few years (for Space Madness) ran
7 times faster than CopyBits on a Quadra 700. That kind of speed difference
means that without the direct access, the game couldn't have been done.

--
Juri Munkki [e-mail]              Life is easy when polygons are cheap.
http://www.iki.fi/~jmunkki                 Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 14 Dec 1995 05:02:10 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] (Jason Regier) writes:
>>    Don't expect every machine to support page flipping, but here's how to
>>    do it. [No machine in recent history has supported page flipping.]
>>
>Although I've never done it, some Macs actually had/have hardware support
>for page flipping-- I believe it was called the Valkyrie chip.  I think
>Juri Munkki might have supported this in Arashi, but he'll have to confirm
>this.

Since you asked...

No, I didn't use actual page flipping to do page flipping. I wanted to have
some static background graphics (the grid and the spikes) single-buffered
and then I needed some double-buffered graphics over those. So, on an 8 bit
display card, I took two bits to make two 1-bit bitplanes and 6 bits to
get one double-buffered 3 bit frame buffer.

The color tables can be arranged so that some bits and/or color combinations
become effectively transparent. There are 10 colors on screen in Arashi:
the background color (black), the grid color, spikes color and seven colors
for double-buffered moving shapes (one color was used for transparent).

It's not a useful method for doing sprites or any kind of filled graphics,
because you are not actually dealing with real bitplaned graphics (like on
the Amiga...not that I would have ever programmed the Amiga). So the
drawing routine has to touch only a few bits at a time in one pixel at
a time (well, you could get 4 pixels if you used a combination of and
and OR). Erasing was done by drawing with the transparent color.

The buffer switch with Arashi happens by changing the color table. Back
then it was the best way to implement Arashi. Machines are now faster and
can do all of it in software, so if I was writing the same game again
today, I might do it differently (mostly to get more colors on screen).

The real page flipping interface is (was?) described in Designing Cards
and Drivers for the Macintosh Family Computers. It's not supported very
widely: I haven't checked recently. Back when I discovered it, I was using
a Mac II with an 8 bit Toby frame buffer (the original Mac II video card).
You could (and still can) have multiple buffers on the Toby.

I was interested in it, because I was doing software for 3D LC-shutter
glasses and they need two buffers for static images and four buffers
for animation. I never used it though, because it only worked in a few
configurations. Oids seems to use it when it is available. It does make
debugging tough, because you might be showing a screen that the window
manager knows absolutely nothing about (no cursor either).

--
Juri Munkki [e-mail]              Life is easy when polygons are cheap.
http://www.iki.fi/~jmunkki                 Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Bretton Wade)
Date: Thu, 14 Dec 1995 01:14:55 -0500
Organization: qualia, inc.

Two little details here...

The PRIMARY reason Apple suggests using CopyBits for image to screen
copying is that it respects all of Apple's internal clipping structures,
and so will correctly update the screen even if your target window is
partially covered by other windows. In game programming, you most likely
have opened a port over the entire screen, and are not at all concerned
about this possibility.

I'd be surprised if Apple write protected the screen any time soon. I
think this because Apple is trying very hard to get game developers to
make games on the mac (sells machines, you know), and the recent push in
the Win95 world to put out a package that gives direct screen access. Game
developers want screen access.

Even if Apple does do something like this, I'll bet the ShieldCursor call
will correctly unprotect the region specified in the rectangle. Note that
ShieldCursor is supposedly called just before every operation which writes
directly to the screen in all of Apple's code. That includes CopyBits. I
understand that Radius uses this fact to its advantage in their
accelerators by informing the hardware of an impending write. It's another
reason to call Shield Cursor whenever you plan to write directly to the
screen.

--
[e-mail]
http://www.qualia.com/

+++++++++++++++++++++++++++

>From [e-mail] (Scott Posch)
Date: 14 Dec 1995 09:37:41 -0600
Organization: /usr/lib/news/organi[sz]ation

As a relatively new MAC game programmer, I have been interested in this
discussion. But, I have a question.

In the "Power PC Optimization" chapter of "Tricks of the MAC Game Programming
Gurus", the author writes a blitter that moves doublewords from a buffer
to an address that he got from a structure. It's either the qd structure,
or a window structure. (Can't remember)

Is this considered writing directly to the screen, or not?

Thanks,
Scott Posch



+++++++++++++++++++++++++++

>From [e-mail] (Eric A. Drumbor)
Date: Sun, 10 Dec 1995 10:05:25 -0700
Organization: BW Software

In article <[e-mail]>,
[e-mail] (Ron Hunsinger) wrote:

> >      I *must* copy directly to the screen.>
>
> No you don't. You can use CopyBits.

     Not if I want to give the opportunity for a good frame rate to a very
low end machine.  It's complete overkill to use CopyBits for a lone pixel,
or to copy a sizable Rect for two changed pixels.  Let me clarify
something, this is going to be an option, not something that the end user
doesn't have control over, as it should be.  So, yes, I do need to write
directly to the screen for this method to be effective.

> > My frame updates/changes are
> > too small and too spread out to use CopyBits.
>
> If that's true, then updating the screen is not your bottleneck. "Small
> and spread out" means you aren't updating very many pixels.

    ...and your point is?  Small and spread out wasn't meant to imply only
a few changed pixels (my fault, won't happen again, sorry sorry).  It's
implying that updated areas of the screen are more or less small, spread
out patches, something that (must I say this again?) CopyBits becomes very
inefficient at when it's being used several hundred times in a frame.

> >      What are the odds this puppy will crash?
>
> 100%. Guaranteed. Sorry to sound so pessimistic, but some of us still have
> the battle scars from ignoring Apple's advice not to write directly to the
> screen. It's good advice. Heed it.
>
> Video memory will not always be memory mapped. Even if it is, it will not
> always be writable. As memory protection improves (as it must if Apple
> wants to make these machines more robust), VRAM won't always be in your
> process' address space, even if it remains in the machine's address space.

     This is what I wanted to hear (an answer to my question).  Thank you,
Ron, at least for this part.  The rest, well....

> How are you "seeing" games use this method. Did you disassemble the code,
> or trace it? If you had, you would *know* whether they were using
> CopyBits, without having to make assumptions.

     Since my first post, yes, I have traced (ugh) through some code.  I
was going on the claims a few people made at the university, but the
claims were true enough.  Go figure...

> >      How are these companies staying compatable with all the different
> > Macs and video configs?
>
> CopyBits will always be able to write to the screen, even when the day
> comes that you can't.

     I know this, my original question wasn't about CopyBits, it was about
using an alternate method.  Of course, what you've said here doesn't
actually answer this question either, does it?

> > Is there some kind of magic function to prevent
> > disaster when trying to write to the video memory of a video card?
>
> Yes. It's called CopyBits.

     Exactly what is the problem here?  I'm trying to determine whether or
not it's viable to use a method I've described above, an *alternative* to
CopyBits, that's all.  Why these little one-liner jabs?  Totally uncalled
for and pathetic.

[snip]

> In fact, I once wrote a benchmark where I put CopyBits head-to-head
> against a handcrafted assembler routine to copy a full screen image
> directly to the screen of a Mac Plus. The assembler routine used a
> sequence of 32 MOVE.L (A0)+,(A1)+ instructions to copy each pair of
> scanlines (32 x 32 = 1024 = 2 * 512), in a loop that repeated 171 times.
> You can't get much tighter than that. But you know what? CopyBits beat it!
> It turns out that, on a Mac Plus at least, CopyBits really is unbeatable.
>
> Now I'm not claiming on the basis of that experiment that CopyBits is
> always unbeatable. Far from it. This is a trick result. It turns out that
> on a Plus, ROM is faster than RAM because it doesn't have to compete with
> video refresh. Consequently, code in ROM (like CopyBits) has a slight edge
> (about 20%) over code in RAM (like my assembler routine). The Plus also
> does not support Color QuickDraw, so the CopyBits on that machine doesn't
> have to mess with Palettes and ColorTables and all that sort of stuff.

     I'm not surprised it beat your routine, but your case simply doesn't
apply to my situation.  I've written my own routine (a full screen
blitter) and found it to be only slightly faster (if at all) when copying
a large Rect, I wasn't surprised in the least.  Another good example of
this is my polygon rasterizing routine (which draws directly into a
GWorld).  When drawing smaller (150 x 150 square for instance) polygons,
I'm getting over three times the speed that FillPoly would produce.  On
the other side, my routine is only about 5% faster than FillPoly when
filling an 832 x 624 screen.  In this case, the overhead of FillPoly is
still hurting the speed, but the actual rasterizing is now the major
bottleneck, and both routines share this bottleneck.  Of course, most of
the polygons I draw aren't filling the screen, and the fact that my
routine cuts out the overhead that is involved when filling a polygon in
QuickDraw means that my frame rate will at least double on average, if not
triple.  This is where the overhead comes into play, and the same goes for
CopyBits, when COPYING SEVERAL SMALL REGIONS.  Ahem...

     If I was copying a large area (or even < 12 smaller areas, like a
32x32 square) there would be no two ways about it, CopyBits would be used
(and IS an option in this game).  However, the overhead of making a few
hundred calls to it per frame is what is killing the speed.  I don't see
why this point has eluded you through my previous message.  It's NOT the
actual copying speed of CopyBits (I shouldn't need to point this out!),
it's the overhead involved in calling it in the first place, along with
the checks for ctSeed, etc.  I've been a firm believer in CopyBits for all
my offscreen->screen blits, and I've even taken a similar stance to your
own, but this situation is different.  This time I'd like to find a happy
alternative, besides providing CopyBits as a solution (again, the user has
a choice).  I want the highest frame rate possible while keeping the
system stable, period.

> But I do want you to notice two key points, that are relevant beyond the
> Mac Plus:
>
> a) Sure, CopyBits had a 20% advantage in code access, but it had no advantage
>    in data accesses, it is much more general-purpose, yet despite all that it
>    still beat my code by several percent. It did not fritter away its
>    advantage through inefficiency.
>
> b) CopyBits, being in ROM, can be tailored specifically for the machine it's
>    running on. It will run on a 68000, it will use 68020 instructions on an
>    '020, it runs native on a PowerMac. Because each ROM is specific to the
>    machine it's installed in, ROM routines like CopyBits can safely do
>    optimizations that you don't dare attempt, unless you're willing to ship
>    your product with a dozen hand-tailored routines, each optimized for a
>    different machine, including machines that haven't even been designed yet.
>    Quite an undertaking.
>
> Apple is fully aware of the importance of CopyBits. You can be sure that
> on any machine they write the ROM for, CopyBits and BlockMove will be
> optimized for that machine to within an inch of their lives.
>
> You can help, though. When you call CopyBits, make sure the rectangles are
> aligned to nice machine boundaries. In B/W, this means you widen the
> rectangles if necessary so the left and right edges are longword aligned.
> Even though this means you'll be copying more pixels, it'll actually be
> faster because CopyBits won't have to do any masking. On an '040, give
> CopyBits the opportunity to use a MOVE16 instruction. On a PowerMac, align
> the rectangle boundaries to double-words, matching the width of the data
> bus. (You can ignore cache row boundaries, since video is never cached.
> Caching video would slow the machine to a crawl.)
>
> Your best bet is to draw to an offscreen buffer (a GWorld), which you
> conceptually divide into a number of nicely aligned rectangles. Keep track
> of which rectangles are "dirty". (If you change any pixel in a rectangle,
> the whole thing is dirty.) Then use CopyBits to copy the dirty rectangles
> to the screen. Coalesce adjacent dirty rectangles when you can, to reduce
> the number of calls. Make sure the source and destination have the same
> ColorTable, so CopyBits can know that it doesn't have to translate color
> indexes.
>
> If your game draws into a movable window that is smaller than the screen
> (always a nice courtesy), make sure the window remains aligned to nice
> boundaries. If the user drags the window, snap it to a nice boundary.
> HyperCard does this, for example. This guarantees that CopyBits won't have
> to shift the data while it moves it. Alternatively, make the GWorld a
> little bigger than the window, so you can shift the window contents in the
> GWorld to align them with the window contents on the screen.

     I decided to leave your advice in case someone missed your post.
It's the standard, good advice on CopyBits, and it helped me a year ago
when I was getting very low frame rates.

     I'm not trying to make an enemy of you Ron, but you're way out in
left field on this one.  I'm only trying to establish whether or not
there's a way to safely access VRAM.  Would it have been so difficult to
answer that particular question, and then mention the good reasons not to
try this?  Apparently so.

     Writing to VRAM isn't illegal, and it certainly isn't immoral.  So
there's no reason for that boo-hoo crap up there.  This is a discussion
group, not an incessant pouting group.  You're only wasting your own time
(and my time for pointing this out to you) by putting in those remarks,
and not even understanding my original post from the start.  If it works
(IF), then it should be used, because it gives users on lower end Macs a
chance to play something (it may mean the difference between playability
and non-playability on low end Macs, why cast them aside when I don't need
to?).  If it works (IF again), it should be an option if (IF yet again) it
has the possibility of causing problems and/or crashing the machine.  In
the case of it causing problems, the user only needs to click a checkbox
in a prefs window to tell the app to use CopyBits, at least that's how it
should be.  Clean and simple...

     Your suggestions (out of place) are good.  The dirty rectangle method
is a very good idea, and I used it (and still do) previous to my original
post.  It's only *so* good though, isn't it?  I definitely write directly
in my GWorld memory, it cuts out quite a bit of (oop, there's that word
again) overhead.  BTW, you failed to mention keepLocal when allocating a
GWorld, since it could go on a video card's own memory and cause problems
if the app attempts to directly access it (and has to some people in the
past, but only on a few cards).  Don't worry Ron, I won't tell anyone..
;-)

     My frame rate jumped from 32 fps up to 48 fps (on average, although
sometimes it was around 53 fps) on a 6100/60 at 832 x 624, by using this
method.  The idea here Ron, whether you wish to acknowledge it or not, is
to provide the best possible speed for the user without crashing the
machine.  That means sometimes rules like not writing directly to VRAM can
be broken, when it works and works better/faster and only if it works at
all.

     BTW, thanks goes out to everyone who did take the time to respond
(and actually answer my question).  I'll post a summary (or maybe this is
better as FAQ material) of the information I've received.  I really
appreciate your replies!

     Let's wrap this up.  I feel (and some others have acknowledged this,
but NOT RON!! I make no claims as to what Ron's opinion is on anything!)
that writing directly to video ram works, but isn't guranteed to work on
all machines, or *any* future Macs or video cards.  When correctly using
the ability to draw directly to video, higher frame rates can be achieved
if an only if the method doesn't crash the machine...in that case, the
method doesn't work, which basically means you're getting 0 (zero) frames
per second :-)  This method should only be used as an option that can be
set by the user.  This allows the user to play the game even if the BAAAD
wittle VRAM blitter is mean and nasty, and doesn't share the
blocks...especially the blue ones.

     Please tune in next time when Bruce discovers he needs a new liver
because of his long term drinking problems, Michael finds out he brought
back more than his luggage from his tour of the islands in the South
Pacific, Jim loves Lisa, but Lisa loves Sarah, and Ron Hunsinger will
undoubtedly tell me how clueless and rude I am.  Thanks and please tune in
again....

--
"Once in a while, a notty little boy loses it and comes after Santa"
Eric A. Drumbor
[e-mail]                 <http://www.nilenet.com/~ericd/>
BW Software

+++++++++++++++++++++++++++

>From [e-mail] (Mark Elliott)
Date: 15 Dec 1995 11:54:00 GMT
Organization: Max-Planck-Institut f. Kohlenforsch. Muelheim

In article <[e-mail]>, [e-mail]
(Bretton Wade) wrote:

(snip)

> I'd be surprised if Apple write protected the screen any time soon. I
> think this because Apple is trying very hard to get game developers to
> make games on the mac (sells machines, you know), and the recent push in
> the Win95 world to put out a package that gives direct screen access. Game
> developers want screen access.
>

Supposing they do. I was thinking how I would fix my own game to take care
of this. I came up with 2 solutions.

1. Use CopyBits for everything. This would basically involve a total
rewrite, since everything I have is optimised around the blitters. All my
sprite handling routines and sprite movement patterns are intended with my
blitters in mind.

2. Carry on as I am, but instead of drawing directly to the screen, Set up
another GWorld, and draw 'directly' to this. Then after all the drawing is
done, CopyBits this entire GWorld to the screen.

It sounds like (2) loses all the advantages of direct screen access (i.e.
speed), but on reflection it isn't so bad. After all, it's only on 68030
machines that I really need those extra few fps. Any hypothetical machines
which might not allow direct screen access will be based on PowerPC chips,
and so will not have any problems (speedwise) with one full-screen
CopyBits per frame.

So, does anyone (Ron ???) want to tell me why this would not work? If I
know now, I can start thinking about other ways to get around this
possible (although IMO unlikely) problem.


(snip)

thanks

Mark

- ------------------------------------------------------------------
Mark C Elliott                           [e-mail]
Max-Planck-Institut                      voice: ([phone]
Fuer Kohlenforschung
Muelheim, Germany
- ------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Mark Elliott)
Date: 15 Dec 1995 11:48:27 GMT
Organization: Max-Planck-Institut f. Kohlenforsch. Muelheim

In article <[e-mail]>, [e-mail]
(Bretton Wade) wrote:

(snip)

> I'd be surprised if Apple write protected the screen any time soon. I
> think this because Apple is trying very hard to get game developers to
> make games on the mac (sells machines, you know), and the recent push in
> the Win95 world to put out a package that gives direct screen access. Game
> developers want screen access.
>

Supposing they do. I was thinking how I would fix my own game to take care
of this. I came up with 2 solutions.

1. Use CopyBits for everything. This would basically involve a total
rewrite, since everything I have is optimised around the blitters. All my
sprite handling routines and sprite movement patterns are intended with my
blitters in mind.

2. Carry on as I am, but instead of drawing directly to the screen, Set up
another GWorld, and draw 'directly' to this. Then after all the drawing is
done, CopyBits this entire GWorld to the screen.

It sounds like (2) loses all the advantages of direct screen access (i.e.
speed), but on reflection it isn't so bad. After all, it's only on 68030
machines that I really need those extra few fps. Any hypothetical machines
which might not allow direct screen access will be based on PowerPC chips,
and so will not have any problems (speedwise) with one full-screen
CopyBits per frame.

So, does anyone (Ron ???) want to tell me why this would not work? If I
know now, I can start thinking about other ways to get around this
possible (although IMO unlikely) problem.


(snip)

thanks

Mark

- ------------------------------------------------------------------
Mark C Elliott                           [e-mail]
Max-Planck-Institut                      voice: ([phone]
Fuer Kohlenforschung
Muelheim, Germany
- ------------------------------------------------------------------

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Fri, 15 Dec 1995 12:23:24 -0500
Organization: Carnegie Mellon, Pittsburgh, PA

[e-mail] (Mark Elliott) writes:
> In article <[e-mail]>, [e-mail]
> (Bretton Wade) wrote:
>
> Supposing they do. I was thinking how I would fix my own game to take care
> of this. I came up with 2 solutions.
>
> 1. Use CopyBits for everything. This would basically involve a total
> rewrite, since everything I have is optimised around the blitters. All my
> sprite handling routines and sprite movement patterns are intended with my
> blitters in mind.

Certainly a pain in the ass, and lots of small CopyBits may be
unacceptably slow.

> 2. Carry on as I am, but instead of drawing directly to the screen, Set up
> another GWorld, and draw 'directly' to this. Then after all the drawing is
> done, CopyBits this entire GWorld to the screen.
>
> It sounds like (2) loses all the advantages of direct screen access (i.e.
> speed), but on reflection it isn't so bad. After all, it's only on 68030
> machines that I really need those extra few fps. Any hypothetical machines
> which might not allow direct screen access will be based on PowerPC chips,
> and so will not have any problems (speedwise) with one full-screen
> CopyBits per frame.

This is certainly workable. (I've done it, and gotten 18 fps for
640x480x8 screens on PPC.)  You don't lose *all* the advantages, since
you're using your custom blitters for all the small sprites. If you
were counting on the optimization of not redrawing the whole screen
each time, you take a relative hit, though. (When I did it, it was for
a full-scrolling game, so I was redrawing the whole screen anyway.)

You were probably thinking of this already, but I will *again*
recommend having a user preference for direct screen access or
direct-to-gworld-then-CopyBits. And it's easy enough to code, since
the complicated drawing code is the same in both cases.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (Yan Lee)
Date: 15 Dec 1995 23:04:09 GMT
Organization: Boston University

Mark Elliott ([e-mail]) wrote:
: In article <[e-mail]>, [e-mail]
: (Bretton Wade) wrote:

: (snip)

: > I'd be surprised if Apple write protected the screen any time soon. I
: > think this because Apple is trying very hard to get game developers to
: > make games on the mac (sells machines, you know), and the recent push in
: > the Win95 world to put out a package that gives direct screen access. Game
: > developers want screen access.
: >

: Supposing they do. I was thinking how I would fix my own game to take care
: of this. I came up with 2 solutions.

I had asked this before....how would apple deny us access to the screen?
I remembered somebody saying that apple can deny access when protected
memory is actually implemented in the system software, but then some
fella from apple mentioned some reason why apple couldn't.  Any ideas?

Tony


+++++++++++++++++++++++++++

>From [e-mail] (Yan Lee)
Date: 16 Dec 1995 02:37:56 GMT
Organization: Boston University

Ron Hunsinger ([e-mail]) wrote:
: In article <[e-mail]>,
: [e-mail] (Mark Elliott) wrote:

: > In article <[e-mail]>,
: > [e-mail] (Ron Hunsinger) wrote:
: >
: > > In article <[e-mail]>,
: > > [e-mail] (Eric A. Drumbor) wrote:
: > >
: > > >      I *must* copy directly to the screen.>
: > >
: > > No you don't. You can use CopyBits.
: >
: > Oh come on Ron. Apple have published guidelines for direct-to-screen drawing.

: The only published guidelines I have seen from Apple is "don't do it".


Check out _develop_ issue #11, page 59.  August, 1992.


: > Direct to screen drawing is not dangerous. Yeah, I am sure that some
: > hardware configurations (eg. strange graphics accelerators) MIGHT cause
: > problems. However, after the initial teething troubles (which are
: > certainly not unique to vram access) I have had essentially NO crashes. I
: > have tested my game on a wide range of 68K and powerpc macs with a fair
: > selection of monitor sizes.

: Change MIGHT to WILL.

: Have you tested your games on the Macs that will be coming out 5 years from now?


My guess is that for 68k there wouldnt be much change.  Didnt apple say
that system 7.5 is the last system that would work for 68k macs?  Anwyas,
as long as there is an option to do "copybits mode,"  he will be safe.


Tony



+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 16 Dec 1995 12:46:26 GMT
Organization: Helsinki University of Technology

In article <4asut9$[e-mail]> [e-mail] (Yan Lee) writes:
>I remembered somebody saying that apple can deny access when protected
>memory is actually implemented in the system software, but then some
>fella from apple mentioned some reason why apple couldn't.  Any ideas?

They would take a performance hit every time QuickDraw was used, because
they would have to "unprotect" the frame buffer bfeore QD could access it.
It makes more sense to run QD as a user level process.

I think they only possible scenario where screen frame buffer access was
denied is an accelerated graphics card that wants to do all of the drawing
itself. Usually though even these cards allow access to the frame buffer
even though it is slower than using the accelerator. I guess an incompatible
card doesn't sell all that well.

--
Juri Munkki [e-mail]              Life is easy when polygons are cheap.
http://www.iki.fi/~jmunkki                 Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (RickGenter)
Date: 16 Dec 1995 11:54:22 -0500
Organization: America Online, Inc. (1-800-827-6364)

>>>
This is certainly workable. (I've done it, and gotten 18 fps for
640x480x8 screens on PPC.)
<<<

On a 7100/66, a raw blit of 640x480x8 has a maximum theoretical rate of
114 fps. I've gotten 113 (obviously with no gameplay). The limiting factor
is VRAM speed, not processor speed.

Rick Genter
Technical Lead, IndyCar Racing II
Papyrus Design Group, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (brian williams)
Date: 16 Dec 1995 10:40:59 -0800
Organization: Stanford University, CA 94305, USA


Eric A. Drumbor <[e-mail]> wrote:
>     I'm not surprised it beat your routine, but your case simply doesn't
>apply to my situation.  I've written my own routine (a full screen
>blitter) and found it to be only slightly faster (if at all) when copying
>a large Rect, I wasn't surprised in the least.  Another good example of
>this is my polygon rasterizing routine (which draws directly into a
>GWorld).  When drawing smaller (150 x 150 square for instance) polygons,
>I'm getting over three times the speed that FillPoly would produce.  On
>the other side, my routine is only about 5% faster than FillPoly when
>filling an 832 x 624 screen.  In this case, the overhead of FillPoly is
>still hurting the speed, but the actual rasterizing is now the major
>bottleneck, and both routines share this bottleneck.  Of course, most of
>the polygons I draw aren't filling the screen, and the fact that my
>routine cuts out the overhead that is involved when filling a polygon in
>QuickDraw means that my frame rate will at least double on average, if not
>triple.  This is where the overhead comes into play, and the same goes for
>CopyBits, when COPYING SEVERAL SMALL REGIONS.  Ahem...
>
>     If I was copying a large area (or even < 12 smaller areas, like a
>32x32 square) there would be no two ways about it, CopyBits would be used
>(and IS an option in this game).  However, the overhead of making a few
>hundred calls to it per frame is what is killing the speed.  I don't see
>why this point has eluded you through my previous message.  It's NOT the
>actual copying speed of CopyBits (I shouldn't need to point this out!),
>it's the overhead involved in calling it in the first place, along with
>the checks for ctSeed, etc.  I've been a firm believer in CopyBits for all
>my offscreen->screen blits, and I've even taken a similar stance to your
>own, but this situation is different.  This time I'd like to find a happy
>alternative, besides providing CopyBits as a solution (again, the user has
>a choice).  I want the highest frame rate possible while keeping the
>system stable, period.
>

        I just wanted to give you game developers another reason why
should ALWAYS have a copybits mode.  I used a nice little test program
called TimeVideo to see how fast my video was and saw something
interesting.  On my 7200/90 I got the following results

8-bit dacs. 832x624 pixels.
pixel size                         8    16    32     bits
CopyBits data rate                33.40 34.13 34.30  MB/s
CopyBitsQuickly data rate         17.38 17.30 17.18  MB/s

        CopyBitsQuickly is a handcoded blitter (which is native for the
ppc).  It does in fact get slightly better results than copybits on an
8100/80, 840av and 950 (and least the machines that I tried it on).  But
on my 7200, copybits is twice as fast!  (and faster than any other machine
I tried, including a 9500/132 with an ATI card).

        I'll bet they're not making use of the 64-bit datapath to VRAM
somehow and it should only require a small change to their blitter,  but
again copybits takes care of it automatically.

(Descent really flies on my machine!)

        I'm not saying you shouldn't have direct-to-screen, just that you
should always have support for copybits, or else you cut your self off
from all future enhancements.

--Brian

+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Sat, 16 Dec 1995 13:14:53 -0800
Organization: ErsteSoft

In article <[e-mail]>,
[e-mail] (Eric A. Drumbor) wrote:

> In article <[e-mail]>,
> [e-mail] (Ron Hunsinger) wrote:
>
> > >      I *must* copy directly to the screen.>
> >
> > >      What are the odds this puppy will crash?
> >
> > 100%. Guaranteed. Sorry to sound so pessimistic, but some of us still have
> > the battle scars from ignoring Apple's advice not to write directly to the
> > screen. It's good advice. Heed it.
> >
> > Video memory will not always be memory mapped. Even if it is, it will not
> > always be writable. As memory protection improves (as it must if Apple
> > wants to make these machines more robust), VRAM won't always be in your
> > process' address space, even if it remains in the machine's address space.
>
>      This is what I wanted to hear (an answer to my question).  Thank you,
> Ron, at least for this part.  The rest, well....

You're welcome.

As for the rest, well... I'm sorry you thought I was being caustic. I
certainly didn't mean it that way. I really am trying to be helpful.

But you started out with a conclusion, instead of a question.

So I answered your question, and tried to get you to understand that your
conclusion should be questioned.

Why was I so emphatic? Because I, too, once thought that I *had to* copy
directly to the screen to get decent performance. I wrote a lot of
programs for the Plus that did just that. Then the Mac II came out and
they all broke. In the post-mortem analysis, I realized that my biggest
mistake was ignoring Apple's advice not to write directly to the screen.

I was already composing my images in an offscreen buffer (GWorlds hadn't
been invented yet) and doing selective copying to the screen. I could have
fixed the off-screen => on-screen copy routines. After all, that was the
only part that broke. But someone posted that CopyBits could do that well
enough, and I was about to reply that, of course not, the overhead in
CopyBits was way too high to make that a serious consideration.

Before saying that, though, I thought I'd set up some benchmarks to test
it, so I'd have some hard numbers to back me up. I described one such
benchmark (a full-screen copy on a Plus), but there were others. What I
found, to my surprise, was that CopyBits was not as much slower as I had
thought, and in some (admittedly pathologic) cases was actually even
faster.

And I had to admit to myself that even where CopyBits wasn't the fastest,
it had a number of advantages, that I tried to convey to you. The biggest
was that it was a single routine that would work on all hardware, past,
present, and future.

> > CopyBits will always be able to write to the screen, even when the day
> > comes that you can't.
>
>      I know this, my original question wasn't about CopyBits, it was about
> using an alternate method.  Of course, what you've said here doesn't
> actually answer this question either, does it?

Your original *conclusion* was that you had to write directly to the
screen. I think this does address that rather directly.

Correct me if I'm wrong, but doesn't "write directly to the screen" mean
"without letting QuickDraw do it"?

It may be that I've been giving undue emphasis to CopyBits at the expense
of all the other graphics routines. That is, you could also use FillPoly,
PaintRect, LineTo, and all the myriad other QuickDraw routines. I've been
saying "CopyBits" where perhaps I should have been saying "QuickDraw", so
my admonition is "Do all your VRAM updating with QuickDraw" rather than
"Do it all with CopyBits".

The reason for that emphasis is that I still have in mind the model for
how I manipulate an image with lots of sprites: build a frame where the
user can't see it, then make it all visible at once. I wouldn't dream of
doing the first part with QuickDraw; that's much too slow. For the second
part, CopyBits is all you need, so it turns out that CopyBits is the only
QuickDraw routine I call (after setup, of course) and I really don't see
any of the others being useful.

And I see you having problems down the road addressing the screen. Just
like some of us had when the Mac II came out. You can be as clever a
programmer as you want, but there was no way to anticipate the need for
SwapMMUMode. In fact, right up until the end, Apple swore up and down that
addresses would never be bigger than 24 bits. Just ask T/Maker (writers of
WriteNow).

And I guessed wrong about how color would be implemented. (Before the Mac
II, color was planar. With the Mac II, it suddenly and unexpectedly became
chunky.)

I did guess right about page flipping, so I wasn't getting everything
wrong. I realized that page flipping was incompatible with the Window
Manager, and there was no way Apple would give up windowing, so page
flipping had to go.

The next hurdle will probably be protection. Just a guess, of course. I
could be wrong again. If you want to take the chance, go ahead. But if I'm
right, then *every* non-QuickDraw alternative will fail.

>      I'm not surprised it beat your routine, but your case simply doesn't
> apply to my situation.

You're not? I sure was!

> Another good example of
> this is my polygon rasterizing routine (which draws directly into a
> GWorld).

I heartily endorse any tricks you want to use in your own GWorlds. That's
your memory, and the whole idea is that you can manipulate it to your
heart's content.

> This is where the overhead comes into play, and the same goes for
> CopyBits, when COPYING SEVERAL SMALL REGIONS.  Ahem...

So don't use CopyBits when copying several small regions. I probably
wouldn't use it at all when copying TO my offscreen area. I'm only
suggesting it for the final copy to the screen, at which time you will
copy a few moderate sized rectangles.

> I don't see
> why this point has eluded you through my previous message.

Likewise.

> It's NOT the
> actual copying speed of CopyBits (I shouldn't need to point this out!),
> it's the overhead involved in calling it in the first place, along with
> the checks for ctSeed, etc.  I've been a firm believer in CopyBits for all
> my offscreen->screen blits, and I've even taken a similar stance to your
> own,

Then we're in agreement. The choice of rectangle size will, of course, be
a tradeoff between excessive calls (too small) and excessive copying (too
large).

> but this situation is different.  This time I'd like to find a happy
> alternative, besides providing CopyBits as a solution (again, the user has
> a choice).  I want the highest frame rate possible while keeping the
> system stable, period.

What bothers me is the large number of games I bought for my Plus that
won't run on later machines. That *really* annoys me. It's a black mark
against those companies that influences my future buying decisions,
assuming the company is even in business.

As long as you make it an option, though, it should be OK. But in that
case, I guess I don't understand your question. It isn't that copying to
the screen is *hard*.

>      I'm not trying to make an enemy of you Ron,

Nor I of you.

> but you're way out in
> left field on this one.  I'm only trying to establish whether or not
> there's a way to safely access VRAM.  Would it have been so difficult to
> answer that particular question, and then mention the good reasons not to
> try this?  Apparently so.

Again, I'm really sorry if I came across too heavy. I thought I was doing
just what you suggest: telling you that no, in my opinion there isn't a
safe way to access VRAM, and then mentioning what I think are good
reasons.

I'm really trying to be helpful, and thought (still think, in fact) that I
was doing so.

>      Let's wrap this up.

Fine with me.

> I feel (and some others have acknowledged this,
> but NOT RON!! I make no claims as to what Ron's opinion is on anything!)
> that writing directly to video ram works, but isn't guranteed to work on
> all machines, or *any* future Macs or video cards.  When correctly using
> the ability to draw directly to video, higher frame rates can be achieved
> if an only if the method doesn't crash the machine...in that case, the
> method doesn't work, which basically means you're getting 0 (zero) frames
> per second :-)  This method should only be used as an option that can be
> set by the user.  This allows the user to play the game even if the BAAAD
> wittle VRAM blitter is mean and nasty, and doesn't share the
> blocks...especially the blue ones.

Although I am puzzled when yet again you jab at me and then say exactly
what I said.

-Ron Hunsinger

+++++++++++++++++++++++++++

>From [e-mail] (Kevin Stone)
Date: 16 Dec 1995 23:53:09 GMT
Organization: South Dakota School of Mines and Technology

: This is certainly workable. (I've done it, and gotten 18 fps for
: 640x480x8 screens on PPC.)
: <<<
:
: On a 7100/66, a raw blit of 640x480x8 has a maximum theoretical rate of
: 114 fps. I've gotten 113 (obviously with no gameplay). The limiting factor
: is VRAM speed, not processor speed.

    The guy who was only getting 18 must have not had ForeColor as Black
and BackColor as White, or the source and destination rectangles were
different sizes.
    I can confirm getting around 100 FPS on my 7100-66, 640x480x8-bit.

BAS


+++++++++++++++++++++++++++

>From [e-mail] (Eric A. Drumbor)
Date: Sat, 16 Dec 1995 21:25:33 -0700
Organization: BW Software

In article <[e-mail]>,
[e-mail] (Ron Hunsinger) wrote:

> As for the rest, well... I'm sorry you thought I was being caustic. I
> certainly didn't mean it that way. I really am trying to be helpful.

     Could've fooled me.  Well, I guess you did fool me ;-)

> But you started out with a conclusion, instead of a question.
>
> So I answered your question, and tried to get you to understand that your
> conclusion should be questioned.

     Not quite.  I mentioned the possibility of the crashing based on
rumors and accounts from experienced programmers, and I knew that certain
games still used
this technique (drawing to the VRAM), so I assumed that there was some
info out there to the contrary of the stories I heard about the crashing.
Hence my question, hence my confusion when you decided to get into the
spew about CopyBits.  Nothing more than that, really.
>
> Why was I so emphatic? Because I, too, once thought that I *had to* copy
> directly to the screen to get decent performance. I wrote a lot of
> programs for the Plus that did just that. Then the Mac II came out and
> they all broke. In the post-mortem analysis, I realized that my biggest
> mistake was ignoring Apple's advice not to write directly to the screen.

     Don't misunderstand my last reply to you.  I don't think you're at
all inexperienced.  Again, my question was based on the experiences of
people who have already been successful at using this little hack.

[snip]

> > > CopyBits will always be able to write to the screen, even when the day
> > > comes that you can't.
> >
> >      I know this, my original question wasn't about CopyBits, it was about
> > using an alternate method.  Of course, what you've said here doesn't
> > actually answer this question either, does it?
>
> Your original *conclusion* was that you had to write directly to the
> screen. I think this does address that rather directly.
>
> Correct me if I'm wrong, but doesn't "write directly to the screen" mean
> "without letting QuickDraw do it"?

     My conclusion was based on my delta copying technique, not a full
blitter that you've been bringing up.  This seems to be the key element
that you're missing here, Ron.  I'm not asking about CopyBits, I'm asking
about direct access.  I know what I need/want to do here, Ron, really I
do.  I didn't think I had to give a full fledged explanation of how and
why I was doing this, besides the fact that I'm implementing a delta
copying method that's damned slow when using CopyBits.

     I understand where you're coming from with CopyBits, but I'm simply
not asking about it.  My question which you were answering to (which
didn't make it in your reply) where I mentioned a "magic" function was
referring to getting a base address for the video memory.

[good info snipped]

> And I see you having problems down the road addressing the screen. Just
> like some of us had when the Mac II came out. You can be as clever a
> programmer as you want, but there was no way to anticipate the need for
> SwapMMUMode. In fact, right up until the end, Apple swore up and down that
> addresses would never be bigger than 24 bits. Just ask T/Maker (writers of
> WriteNow).
>
> And I guessed wrong about how color would be implemented. (Before the Mac
> II, color was planar. With the Mac II, it suddenly and unexpectedly became
> chunky.)
>
> I did guess right about page flipping, so I wasn't getting everything
> wrong. I realized that page flipping was incompatible with the Window
> Manager, and there was no way Apple would give up windowing, so page
> flipping had to go.
>
> The next hurdle will probably be protection. Just a guess, of course. I
> could be wrong again. If you want to take the chance, go ahead. But if I'm
> right, then *every* non-QuickDraw alternative will fail.

     This is all very true, and I can see where you're coming from.  I
should mention here and now that the 3D engine I'm working on is PowerMac
only, for the moment.  Obviously this doesn't change the VRAM access
issue, but it cleans up the 32-bit problems (unless a 64-bit
implementation of a PPC would cause problems).

> >      I'm not surprised it beat your routine, but your case simply doesn't
> > apply to my situation.
>
> You're not? I sure was!

     Did you use inline assembly, or did you write your entire
function/procedure in assembly?  If it's the former, I'm not surprised,
since I had a few problems myself.  If the latter, hell, I dunno.

[snip]

> > This is where the overhead comes into play, and the same goes for
> > CopyBits, when COPYING SEVERAL SMALL REGIONS.  Ahem...
>
> So don't use CopyBits when copying several small regions. I probably
> wouldn't use it at all when copying TO my offscreen area. I'm only
> suggesting it for the final copy to the screen, at which time you will
> copy a few moderate sized rectangles.

     Ah, but this is the whole point to a delta blitter, and the reason
why CopyBits doesn't cut it.  My main issue with this blitter is speed
(duh), but I won't get it using CopyBits.  More effective usage of
CopyBits yields better results (from 32 fps to 44 fps), but the delta
blitter has an even greater increase (about 76 fps; all this is on a
6100/60 w/DRAM video BTW).  I want to provide the best frame rate I can,
because eventually I'm porting this to 68k and I *know* it's going to
suffer horribly unless I take care of all the details.

> > I don't see
> > why this point has eluded you through my previous message.
>
> Likewise.

     To shay (sp?).

[snip]

> What bothers me is the large number of games I bought for my Plus that
> won't run on later machines. That *really* annoys me. It's a black mark
> against those companies that influences my future buying decisions,
> assuming the company is even in business.

     Well, that's more of a support issue isn't it?  Obviously it's
annoying to get a new Mac only to find that your favorite game crashes on
it, but if a company is willing to put in the time to find a
solution/workaround I don't see *too* much of a problem.  We could get
into this aspect a little more but, ugh, only if you really want to...

> As long as you make it an option, though, it should be OK. But in that
> case, I guess I don't understand your question. It isn't that copying to
> the screen is *hard*.

     I just didn't get into the little details, and I didn't see a point
in it.  I could've explained all kinds of things about my final
intentions, but I think that's a waste of time and bandwidth.  It's easier
to ask a question if someone just gets to the point instead of someone
babbling on.  I see my folly, next time I'll offer more information.

> Although I am puzzled when yet again you jab at me and then say exactly
> what I said.

     Heh, two things:

1)  It wasn't a jab.  Honestly, Ron, it was a friendly "push".  Don't read
into it.

2)  We agreed on the point that you brought up.  My original question was
based on my wondering why these companies were using a method deemed WRONG
by Apple and others.  I wanted to know if there was a way to get access to
VRAM without using QD, and as the title says, doing it "(Safely)".  Your
point is definitely nothing to ignore, I just wanted to know what the deal
was with accessing the VRAM on my.

     I'm tired, and Christmas shopping has me quite ragged, so let's agree
to agree, and agree to disagree.....or whatever.

--
"Once in a while, a naughty little boy loses it and comes after Santa"
Eric A. Drumbor
[e-mail]                 <http://www.nilenet.com/~ericd/>
BW Software

+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Mon, 18 Dec 1995 14:41:06 -0800
Organization: ErsteSoft

In article <[e-mail]>,
[e-mail] (Mark Elliott) wrote:

> 2. Carry on as I am, but instead of drawing directly to the screen, Set up
> another GWorld, and draw 'directly' to this. Then after all the drawing is
> done, CopyBits this entire GWorld to the screen.
>
> It sounds like (2) loses all the advantages of direct screen access (i.e.
> speed), but on reflection it isn't so bad. After all, it's only on 68030
> machines that I really need those extra few fps. Any hypothetical machines
> which might not allow direct screen access will be based on PowerPC chips,
> and so will not have any problems (speedwise) with one full-screen
> CopyBits per frame.
>
> So, does anyone (Ron ???) want to tell me why this would not work? If I
> know now, I can start thinking about other ways to get around this
> possible (although IMO unlikely) problem.

That is, essentially, the solution I'm recommending.

As I spelled out in an earlier post, you don't necessarily want to do a
single copybits for the whole screen. It may (depending on the game) be
better to divide the screen up into a number of smaller rectangles, and
selectively copybits only those rectangles that have changed. This gains
in a game like PacMan where the difference from one frame to the next is
typically in only a few parts of the screen. If you have a game like
Marathon where each frame is usually completely different from the next,
you would go ahead and copybits it in one operation.

Actually, there are a number of advantages to this approach (of drawing
offscreen and then copying (somehow) to the screen):

  a) It solves completely the problem of flicker. All you have to do to
     avoid flicker is follow one simple rule: never put on the screen
     anything you don't want the user to see.

     For example, if you want to move a sprite, the naive way is:
         Erase it from its old position (by copying background over it)
         Draw it in the new position.

     If you do that on the screen, though, you get flicker because the
     first step (erasing) involves drawing something (the absence of the
     sprite) that you don't want the user to see.

     If you do it offscreen, there's no problem. You don't copy the
     image to the screen until both the erasure and the redraw have been
     done. (If you're copying selectively, remember that both the
     erasure and the redraw are changes.)

  b) You probably have more than one sprite, and they can probably
     overlap. To make this look right, you have to erase all your sprites,
     then draw them all in their new position. To make the overlap look
     right, you have to draw them in back-to-front order. This is not
     likely to be the same as top-to-bottom order, which is the order
     you want to update the screen in.

     Splitting the drawing into separate passes makes your logic a lot
     simpler. Simplicity usually (and does in this case) translate into
     speed. You've probably already done this anyway, and the only real
     issue is how you get your data from offscreen to onscreen.

Some people still suggest dealing with flicker by synchronizing to
vertical retrace, and doing all your drawing ahead of the electron beam.
In practice, that isn't practical. You would have to be able to do all
your erasing/drawing during vertical retrace time, which is only a
fraction of the frame time.

If you could organize the drawing top-to-bottom, you could theoretically
get a little more time, because you don't have to be finished by the time
the beam starts drawing the top of the screen; you only have to stay ahead
of it. But if you have overlapping sprites, top-to-bottom isn't a natural
order to draw in.

And even if it were, if your machine were fast enough (or your image
simple enough) to stay ahead of the beam, we wouldn't be having this
discussion. Not to mention that time spent waiting for VBL (assuming you
can beat it) is time wasted.

As long as your offscreen->onscreen copy is top-to-bottom, you aren't
going to get any flicker, even if you don't wait for VBL. As Forest Gump
would say, "One less thing to worry about."

So I've been assuming that people would draw offscreen first. The only
issue was, how to copy it onscreen quickly. The choices were: CopyBits, or
a custom copy routine.

I'm in favor of CopyBits, because it will always work, even on future
machines, and in the benchmarks I ran (admittedly several years ago) it
turned out that CopyBits is not all that slow IF USED JUDICIOUSLY.

Judiciously means:

   - you copy only rectangles that are nicely aligned (both source and
     destination) to nice machine boundaries, so CopyBits won't have to
     do any masking or shifting.

   - your source and destination use the same color table, so CopyBits
     knows it doesn't have to translate colors. It only has to move pixels.

   - you copy as few rectangles as possible, subject to the contrary goal
     that you don't want the rectangles to be so large that they include
     too many pixels that haven't changed.

   - You don't copy anything twice. That is, you don't keep a list of
     sprite rectangles, and copy all of them -- that would copy the same
     data twice if sprites overlapped. Instead you keep a map of dirty
     (changed) rectangles, and copy those, once each. Where possible,
     combine adjacent rectangles, to minimize the number of calls.

If you follow those guidelines, I doubt that using CopyBits instead of a
custom copy routine will affect your frame rate by more than 5%. On some
machines, it may even be faster to use CopyBits than anything you can
write.

Keep in mind that your offscreen drawing time will be greater than the
offscreen->onscreen copy time, since offscreen you do have to worry about
masking, shifting, clipping, colorizing, erasing, and all that good stuff.
This will dilute the significance of any relative difference in speed that
there may be in the to-screen copy.


I want to make it very clear (because apparently some people misunderstood
this) that the danger I see in writing directly to the screen is primarily
one of portability, to future machines, or to future operating systems.
(But see below.) I did not mean to suggest that a game that writes
directly to the screen might be unreliable or cause occasional random
crashes.

It either works or it doesn't. If it works on a particular machine, it
will keep working on that machine (hardware and software). Change either,
and it may fail, but it's not going to fail in the middle of a game. You
don't have to worry about someone reconfiguring the machine while you're
playing. (Except for the usual stuff -- pixel depths and maybe the
occasional Radius swivel -- that you have to worry about anyway.)

But your users will curse you if the game stops working because they
upgraded, whether it's to a new machine, or a new video card, or a new OS.
[Don't overlook that even an '030 has the hardware to write protect the
screen. It is possible than a new OS will use that capability. Not likely,
considering that Copeland may never run on an '030, and its successor
definitely won't. But possible.]

If you make it a preference, be sure your game can run long enough without
writing to the screen to reach the preference dialog. Don't, for example,
write directly to the screen to do any animation in your startup splash
screen, even if the preference says you can, because you may be restarting
from the crash that came right after the preference was set. Probably
obvious, but I just thought I'd mention it.

CopyBits does solve a few software compatibility problems, even on current
hardware and OS:

     The user can put the game into the background and let it continue
     playing. Not useful for most games, but think about SimCity. This
     will force CopyBits to start clipping around foreground windows, but
     it already knows how to do that. There's no point in you reinventing
     that wheel. If the user doesn't like the slowdown, they'll know what
     to do about it.

     The user can even put a window in front of the game window and still
     play. I've seen utilities that put floating palettes in front of
     all the windows on the screen. (The name "Desk Strip" comes to mind,
     but I don't know if that's right.) I don't use such things, but I know
     people who swear by them. You're compatible with such utilities if
     you use CopyBits, because CopyBits knows to clip around windows that
     you don't even know are there.

     It even knows to "clip around" screen savers. Of course, there's a
     Gestalt you can use to detect when a screen saver has kicked in,
     but not all screen savers use it. And the real point of this point
     is that CopyBits (actually, the Window Manager) will know about weird
     stuff like this without your having to worry about. With CopyBits,
     you've covered bases you haven't even thought of.

-Ron Hunsinger

+++++++++++++++++++++++++++

>From [e-mail] (Renaud HEBERT)
Date: 19 Dec 1995 12:28:07 GMT
Organization: Lab. PRiSM, Universite de Versailles-Saint Quentin, France

In article <[e-mail]>, [e-mail] (Ron Hunsinger) writes:
|> In article <[e-mail]>,
|> [e-mail] (Mark Elliott) wrote:
[things cut]
|> As long as your offscreen->onscreen copy is top-to-bottom, you aren't
|> going to get any flicker, even if you don't wait for VBL. As Forest Gump
|> would say, "One less thing to worry about."
True, no flicker but I think that you can have some tearing ie you have two
different frames on the screen at the same time.
Does anyone know if people don't notice this "tearing" or does it look ugly ?

--
Renaud HEBERT          E-mail: [e-mail]
Serveur WWW:        http://www.prism.uvsq.fr
"Si utiliser un avion, c'est voler, alors utiliser un bateau c'est nager.
Si vous voulez sentir l'élément, sortez du véhicule." Bonne chute!




+++++++++++++++++++++++++++

>From [e-mail] (Al Evans)
Date: 19 Dec 1995 07:57:31 -0600
Organization: Powertools, Austin, Texas

In article <4b6b4n$[e-mail]>,
Renaud HEBERT <[e-mail]> wrote:

[in response to a long post from Ron Hunsinger, with which I agree in
almost every detail...]

>True, no flicker but I think that you can have some tearing ie you have two
>different frames on the screen at the same time.
>Does anyone know if people don't notice this "tearing" or does it look ugly ?

This is a theoretical possibility, but in years of staring at screens
during the development of Graphic Elements, I am not sure I have ever
seen it. It certainly has never seemed an adequate reason for waiting
up to 12 ms or so for the next vertical blanking interrupt.

>Renaud HEBERT         E-mail: [e-mail]
>Serveur WWW:        http://www.prism.uvsq.fr
>"Si utiliser un avion, c'est voler, alors utiliser un bateau c'est nager.
>Si vous voulez sentir l'élément, sortez du véhicule." Bonne chute!

Euh...on sait bien nager sans bateau, mais voler sans avion? Je passe.

                                        --Al Evans--
--
|||| Al Evans -- [e-mail] -- proud of Graphic Elements Release 3 ||||
====  A new standard for high-performance interactive Macintosh graphics  ====
====         Available from mac.archive.umich.edu and mirrors in          ====
||||        /mac/development/libraries/graphicelements3.0.sit.hqx         ||||

+++++++++++++++++++++++++++

>From [e-mail] (David Wareing)
Date: Mon, 18 Dec 1995 02:19:10 +0930
Organization: Weyland Yutani

In article <[e-mail]>,
[e-mail] (Ron Hunsinger) wrote:

>> > >      I *must* copy directly to the screen.>
>> >
>> > No you don't. You can use CopyBits.
>>
>> Oh come on Ron. Apple have published guidelines for direct-to-screen drawing.
>
>The only published guidelines I have seen from Apple is "don't do it".

I respect your views on the subject Ron, and I do realise that you
are only reiterating what we should all know and practice, but the
(sad) fact of the matter is that Apple doesn't write games, nor have
they presented a viable alternative for game/multimedia programmers.

(BTW Apple, where's the Game Dev home page? Microsoft is showing you
up. And give us a scaled down version of QD3D while you're at it. Oh,
and you might want to do something about the incredibly lacklustre
Pippin home page too. Whine finished.)

CopyBits is a generic solution for general problems. Yep, it's very
nifty and can do things our custom blitters couldn't hope to do, but
that's part of the problem -- it does too much. People use their
own solutions for speed reasons, especially when many small copies
are required. There's just no way that CopyBits is going to be able
to beat a custom blitter in a game like Swoop (sorry for the plug
but I didn't want to speak for other people) on a low end machine
without hardware acceleration. Could Swoop be incompatible on next
year's Macs? Sure, there is that risk. But in the mean time, it will
will run at a decent clip on last year's Macs. I did err in not providing
a "QuickDraw only" option in Swoop, but my future work will rectify
that oversight.

>> Direct to screen drawing is not dangerous. Yeah, I am sure that some
>> hardware configurations (eg. strange graphics accelerators) MIGHT cause
>> problems. However, after the initial teething troubles (which are
>> certainly not unique to vram access) I have had essentially NO crashes. I
>> have tested my game on a wide range of 68K and powerpc macs with a fair
>> selection of monitor sizes.
>
>Change MIGHT to WILL.
>
>Have you tested your games on the Macs that will be coming out 5 years
from now?

Have you Ron? :-)  We can worry about the future all we like, but our
games have to run at respectable speeds right here and now. If you're
writing a full screen copy game then I can see how it would be very,
very wise to use GWorlds and CopyBits, but I can't see the advantages
if you're writing a sprite-based affair that needs to run on older
machines.

[snip]

>> I have disassembled many action games. In almost all cases, games which
>> are highly rated (eg. the Ambrosia games) use direct to screen drawing. I
>> have yet to see one of these games crash.
>
>They will. Not on the machines that they are running on (obviously). But
>they won't run on the machines that will be on the market in five years.
>Nor on a Mac II, at least not at first.

Are you sure about that last statement?

>Getting the base address is nice. That's what we did on the early
>machines. We didn't call it GetBaseAddr, of course. We called it
>screenBits.baseAddress, and for all anyone knew at the time, that (and the
>rest of screenBits) was all you needed to know. Ask anybody. They'd tell
>you. That was how you did it, and it was perfectly safe.
>
>Except for Apple, of course. Those wet blankets kept saying "Don't write
>to the screen. Your program will crash on future Macs." But hey, what did
>they know? And what's that you say about "device list", "pixMap", and all
>that? We didn't worry about things like that, because things like that
>hadn't been invented yet.

Don't get confused about the intentions of people who are bypassing
CopyBits. I think that most people would *much* prefer to use Apple's
API rather than roll their own code. The problem is that Apple's code,
as I stated above, is not up to spec for certain requirements. If Apple
wants to bring out a "DirectDraw" SDK that is actually usable, then I'll
be the first in line to use the sucker. But until they do, their
warnings re compatibility are falling on less than sympathetic ears.

A similar situation existed with the old Sound Driver. How many people
do you think really wanted to write their own solution? I sure wouldn't
have. I'd rather use Apple's, but that only became a realistic option
when SM 3.0 was released. Note that I'm not saying CopyBits is technically
equivalent to the old Sound Manager. I'm saying that there's a time to
give CopyBits a big miss.

>What things are you overlooking that haven't been invented yet?

Umm, a version of Open Transport that works? A MacOS with protected
memory? An Apple Virtual Memory that works quickly and efficiently?
 :-) ;-)

[snip]

>> Okay, very good advice about CopyBits, but what about the situations where
>> CopyBits is not fast enough. Direct to screen drawing can be much faster.
>> For a sprite game (which is what I am writing) you generally know what
>> sort of movement your sprites will have, and how best to handle them.
>> Depending on your game, there are a huge number of optimisations you can
>> make.
>
>I accept that direct-to-screen may be a little faster, but I don't believe
>that it's going to be a lot faster.

I can say with religious certainty that the drawing loop in Swoop runs
at *least* *twice* as fast as the *optimised* CopyBits method on an
030. And since Swoop spends most of its time in that drawing loop...

BTW, Ron, how exactly would you go about drawing several thousand
stars to the screen (followed by erasing them by looking up their
old values and substitution) on a low end Mac? In real time please. ;-)

All warnings duly noted, but it's still horses for courses, IMO. I
won't be whining about incompatibility if Swoop breaks on new Macs
(though I might be whining if Apple still haven't got their act
together in the software dept).

--
David Wareing                                 [e-mail]
Belair, South Australia           http://www.AmbrosiaSW.com/~dwareing/
Macintosh Games & Multimedia Programming


+++++++++++++++++++++++++++

>From [e-mail] (Karl A. Bunker)
Date: Wed, 20 Dec 95 12:26:11 EDT
Organization: MacEAST

> True, no flicker but I think that you can have some tearing ie you have two
> different frames on the screen at the same time.
> Does anyone know if people don't notice this "tearing" or does it look ugly
?

It depends on the type of animation, or more specifically, the type of sprite
movment. If a sprite has a lot of fast horizontal movement, tearing can become
a real problem, because that's when the top and bottom pieces of the sprite
will be markedly offset from each other. This is assuming that the sprite is
unfortunate enough to have its drawing interrupted by a screen-refresh, so
that it gets drawn in two sections.

Karl Bunker


--

- ---------------------
via MacEAST, Boston
http://www.maceast.com/

+++++++++++++++++++++++++++

>From Jim Lloyd <[e-mail]>
Date: 21 Dec 1995 02:05:19 GMT
Organization: MelonGem Productions

In article <4b6b4n$[e-mail]> Renaud HEBERT,
[e-mail] writes:
>In article <[e-mail]>, [e-mail] >(Ron Hunsinger) writes:
>|> In article <[e-mail]>,
>|> [e-mail] (Mark Elliott) wrote:
>[things cut]
>|> As long as your offscreen->onscreen copy is top-to-bottom, you aren't
>|> going to get any flicker, even if you don't wait for VBL. As Forest Gump
>|> would say, "One less thing to worry about."
>True, no flicker but I think that you can have some tearing ie you have two
>different frames on the screen at the same time.
>Does anyone know if people don't notice this "tearing" or does it look ugly ?

Yes, you can get tearing even if you compose each frame offscreen and
render in one CopyBits.  If you have any sprites that have a high
horizontal velocity,
the tearing can be quite noticable (and annoying).

Jim Lloyd
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (David Wareing)
Date: Sun, 24 Dec 1995 12:58:00 +0930
Organization: Weyland Yutani

In article <4av3rr$[e-mail]>, [e-mail]
(brian williams) wrote:

>        I just wanted to give you game developers another reason why
>should ALWAYS have a copybits mode.  I used a nice little test program
>called TimeVideo to see how fast my video was and saw something
>interesting.  On my 7200/90 I got the following results
>
>8-bit dacs. 832x624 pixels.
>pixel size                         8    16    32     bits
>CopyBits data rate                33.40 34.13 34.30  MB/s
>CopyBitsQuickly data rate         17.38 17.30 17.18  MB/s

Now do it for 50 rects, each 32x32 or smaller...

Or, try plotting 10000 random points to the screen...

--
David Wareing                                 [e-mail]
Belair, South Australia           http://www.AmbrosiaSW.com/~dwareing/
Macintosh Games & Multimedia Programming


+++++++++++++++++++++++++++

>From [e-mail] (K. & G. Stahl)
Date: 27 Dec 1995 06:05:22 GMT
Organization: InfoNet Communications


> In article <4b6b4n$[e-mail]> Renaud HEBERT,
> [e-mail] writes:
> >True, no flicker but I think that you can have some tearing ie you have two
> >different frames on the screen at the same time.
> >Does anyone know if people don't notice this "tearing" or does it look ugly ?

Tearing does look ugly.  Just think of half the screen being one frame and
the other half being another with a "tear" in between.  The only time I
have visibly noticed tearing was large images or sprites.  With small
reasonable speed sprites any small "tears" are not sync'd with other
sprites so one does not notice.  I has been meantioned that fast
horizontal movement can make the bottom half of the torn sprite out on
line with the top.  One can test this with a vertical bar moving
horizontally in response to mouse movement.  It should be trival to make a
tear visible.
  I feel if one is reasonably careful in implementing their blitter (using
the suggestions in this thread) that tearing is a small problem that can
be dealt with if it appears on a case by case basis.  Waiting for VBL's is
just a waste of time since you cannot draw fast enough to keep ahead of it
and that is lost time you could be doing more cool things...

Just my 2 sense

Regards,
Geoff Stahl
Dog Star Development
[e-mail]

---------------------------

>From [e-mail] (Emil Tin)
Subject: ANSWER: Get dirID from FSSpec
Date: Sat, 23 Dec 1995 14:09:18 +0200
Organization: News Server at UNI-C, Danish Computing Centre for Research and Education.

After downloading the MoreFiles 1.4 Apple Sample Code (se previous posts),
I modified one of the routines to get from a FSSpec describing a directory
to that directory's dirID. Here's the C++ code:

The GetFolderDirID.cp:

//
// Get a folders directory ID from its FSSpec.
// Based on the Apple Sample Code, MoreFiles 1.4.
//
//                                     ◊ Emil Tin    95.12.23 ◊
//

#include "GetFolderDirID.h"

OSErr GetFolderDirID (FSSpec& folder, long& resultDirID)
{
   CInfoPBRec  pb;
   Str31    tempName;
   OSErr    error;

   if( (folder.name == NULL) || (folder.name[0] == 0) )     //Protection
against File Sharing problem
   {
      tempName[0] = 0;
      pb.dirInfo.ioNamePtr    =  tempName;
      pb.dirInfo.ioFDirIndex  =  -1;            //use ioDirID
   }
   else
   {
      pb.dirInfo.ioNamePtr    =  folder.name;
      pb.dirInfo.ioFDirIndex  =  0;          //use ioNamePtr and ioDirID
   }

   pb.dirInfo.ioVRefNum       =  folder.vRefNum;
   pb.dirInfo.ioDrDirID       =  folder.parID;

   error = PBGetCatInfoSync( &pb );

   resultDirID          =  pb.dirInfo.ioDrDirID;

   if( !((pb.dirInfo.ioFlAttrib & ioDirMask) != 0) )
      return dirNFErr;                    //not a folder!

   return error;
}

- ----
The GetFolderDirID.h file:

//
// Get a folders directory ID from its FSSpec.
// Based on the Apple Sample Code, MoreFiles 1.4.
//
//                                     ◊ Emil Tin    95.12.23 ◊
//

#pragma once


OSErr GetFolderDirID    (FSSpec& folder, long& resultDirID);

---------------------------

>From [e-mail] (jeremyj)
Subject: Animation Libraries
Date: 20 Dec 1995 00:25:11 -0500
Organization: DataXchange Network

Hey everybody, got a question for ya!

I just finished reading through the docs of SAT (Ingemar, since I know
you're listening, great work!), and it has left me thinking that there
have to be more libraries out there, 'specially those that I can use in
Pascal (I know C now, but I can't afford a compiler and hate translating
source code). Are there any libraries anybody has or know of that do
vector graphics (like in Arashi) polygon graphics (like in Xwing) and/or
scrolling graphics systems? SAT *can* scroll graphics, but is there
anything out there that can do it faster (is it even possible to do it at
a reasonable rate?).

Please post your results here; don't just email me. This is stuff anybody
can benefit from. Oh, and don't try to email me at the address above;
look below.

-JRJ
[e-mail]

:)

+++++++++++++++++++++++++++

>From Tom Lakovic <[e-mail]>
Date: 20 Dec 1995 19:28:13 GMT
Organization: Simon Fraser University

Yes, Christian Franz has written a vector graphix library called 3D
GrafSys. Worth checking out, though I've never even been close to using
it myself.

Tom.



+++++++++++++++++++++++++++

>From Ed Draper <[e-mail]>
Date: 21 Dec 1995 14:39:05 GMT
Organization: U.T.M.D. Anderson Cancer Center

In article <4b86nn$[e-mail]> jeremyj, [e-mail] writes:
>Please post your results here; don't just email me. This is stuff anybody
>can benefit from. Oh, and don't try to email me at the address above;
>look below.

I highly recommend ACL from Virtually Unlimited.  It's easy to use, fast,
cheap, and is loaded with features:

ftp://FTP.VIRTUALLY.MCNET.CH/virtually/acl/

You should find a demo on the CW7 CD.


      |E|J-  ED DRAPER
 rEpar|D|<-  The Levit Radiologic/Pathologic Institute
             The University of Texas M.D. Anderson Cancer Center
             mailto:[e-mail]
             http://rpisun1.mda.uth.tmc.edu/
             http://www.blkbox.com/~draper/

+++++++++++++++++++++++++++

>From [e-mail] (Christoph Bergmann)
Date: Sun, 24 Dec 1995 12:36:48 +1000
Organization: University of Queensland

In article <4b86nn$[e-mail]>, Email replies are not possible to
this user wrote:

> source code). Are there any libraries anybody has or know of that do
> vector graphics (like in Arashi) polygon graphics (like in Xwing) and/or

there are a few 3d libs out there.. i dunno how well they rate but i've
seen them around..

> scrolling graphics systems? SAT *can* scroll graphics, but is there
> anything out there that can do it faster (is it even possible to do it at
> a reasonable rate?).

depends on what computer on. a pb180 (33mhz 030, 16greys) can handle
scrolling (1/2 - 3/4 screen size) no problems with well-written code..
even without using custom blitters. i wouldnt advise trying it on a slower
machine if u want good speed. also higher colour depths would slow it
down..
as to the library for it, i havent heard of any apart from sat and
spriteWorld or whatever its called. neither seem to have much scrolling
support from what i have seen of them.

ChrisB

+++++++++++++++++++++++++++

>From [e-mail] (Gordon Henriksen)
Date: 24 Dec 1995 18:12:44 GMT
Organization: Micron Internet Services

In article <[e-mail]>,
[e-mail] (Christoph Bergmann) wrote:

> In article <4b86nn$[e-mail]>, Email replies are not possible to
> this user wrote:
>
> > source code). Are there any libraries anybody has or know of that do
> > vector graphics (like in Arashi) polygon graphics (like in Xwing) and/or
>
> there are a few 3d libs out there.. i dunno how well they rate but i've
> seen them around..
>
> > scrolling graphics systems? SAT *can* scroll graphics, but is there
> > anything out there that can do it faster (is it even possible to do it at
> > a reasonable rate?).
>
> depends on what computer on. a pb180 (33mhz 030, 16greys) can handle
> scrolling (1/2 - 3/4 screen size) no problems with well-written code..
> even without using custom blitters. i wouldnt advise trying it on a slower
> machine if u want good speed. also higher colour depths would slow it
> down..
> as to the library for it, i havent heard of any apart from sat and
> spriteWorld or whatever its called. neither seem to have much scrolling
> support from what i have seen of them.

ACL provides extensive support for scrolling. ACL costs US$250.

> ChrisB

                      TTFN,
                        Gordon Henriksen
                        [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 27 Dec 1995 09:56:00 GMT
Organization: (none)

[e-mail] (jeremyj) writes:

>I just finished reading through the docs of SAT (Ingemar, since I know
>you're listening, great work!),

Thanks!

>and it has left me thinking that there
>have to be more libraries out there, 'specially those that I can use in
>Pascal (I know C now, but I can't afford a compiler and hate translating
>source code). Are there any libraries anybody has or know of that do
>vector graphics (like in Arashi)

I actually made a Pascal interface for VAKit (Arashis reusable parts) once.
Now, where did I put it...

>polygon graphics (like in Xwing)

3DGM could fit the bill - though it doesn't come with a Pascal interface
yet.

>and/or
>scrolling graphics systems? SAT *can* scroll graphics, but is there
>anything out there that can do it faster (is it even possible to do it at
>a reasonable rate?).

It is hard to scroll faster than SAT does - without scrolling in bigger
steps, of course. (Perhaps the scrolling demo would be more impressing if
I just bumped up the speed of the objects a little bit?) On low-end Macs,
step-scrolling is often preferrable. On new Macs, you can scroll pretty fast.

SAT's approach to smooth scrolling is simply to CopyBits from a part of
a large offscreen. You can, of course, fake scrolling by using starfields
(part of SAT since 2.3.5) or sprites, but that isn't the same.

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 27 Dec 1995 10:10:13 GMT
Organization: (none)

Tom Lakovic <[e-mail]> writes:

>Yes, Christian Franz has written a vector graphix library called 3D
>GrafSys. Worth checking out, though I've never even been close to using
>it myself.

I have been using parts of it for some 3D hacks I've been doing.

First of all, a library is missing from the 2.0 package. I got it directly
from Christian. It is included below.

The package is written using floating-point numbers. There is some fixed-
point support, but it is half-hearted (still using lots of floating-point
operations) and doesn't work right out of the box. This means that it
shouldn't be very fast on a 68LC040 (LC475, LC630...).

The package is worth getting only for the documentation. You can learn quite
a bit of 3D from it.

I use only the fundamental matrix operations, which I made run with
fixed-point.

/Ingemar Ragnemalm


--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Al Evans)
Date: 27 Dec 1995 07:44:56 -0600
Organization: Powertools, Austin, Texas

In article <4br57g$[e-mail]>,
Ingemar Ragnemalm <[e-mail]> wrote:

>[e-mail] (jeremyj) writes:

>>SAT *can* scroll graphics, but is there
>>anything out there that can do it faster (is it even possible to do it at
>>a reasonable rate?).

>It is hard to scroll faster than SAT does - without scrolling in bigger
>steps, of course. (Perhaps the scrolling demo would be more impressing if
>I just bumped up the speed of the objects a little bit?) On low-end Macs,
>step-scrolling is often preferrable. On new Macs, you can scroll pretty fast.

Graphic Elements offers support for scrolling, presumably in somewhat
the same way as does SAT.

The *problem* with scrolling backgrounds is that, when the background is
scrolling, everything on the screen will have to be redrawn every frame.
This implies a fundamental rendering strategy in which you take for
granted one complete redraw per frame. However, the high performance of
Graphic Elements (and presumably SAT) is based on the assumption that
much of the disply will remain static from one frame to the next. When
this assumption is false (i.e., when the whole frame must be redrawn),
there is a small amount of additional overhead due to this now-false
assumption.

(Now *there* is an obtuse paragraph. Just read "...dirty rects become
irrelevant when all rects are dirty.")

>SAT's approach to smooth scrolling is simply to CopyBits from a part of
>a large offscreen. You can, of course, fake scrolling by using starfields
>(part of SAT since 2.3.5) or sprites, but that isn't the same.

As part of my "rewrite" of Cap'n Magneto, I made a scrolling pattern-based
"background map" Graphic Element. Performance was quite acceptable on
my Quadra 800. But to write a "modern" side-scroller, with 2 or 3
planes scrolling at different rates and with transparency, would in my
opinion require a dedicated graphics engine.

                                        --Al Evans--
--
|||| Al Evans -- [e-mail] -- proud of Graphic Elements Release 3 ||||
====  A new standard for high-performance interactive Macintosh graphics  ====
====         Available from mac.archive.umich.edu and mirrors in          ====
||||        /mac/development/libraries/graphicelements3.0.sit.hqx         ||||

---------------------------

>From Michele Fuortes <[e-mail]>
Subject: Changing the size of balloon help
Date: 27 Dec 1995 00:29:26 GMT
Organization: Cornell University Medical College

Hi everybody,

I'd like to add balloon help to my dialog windows, but I'm having
troubles with the sizes of the balloons.

I'd like a balloon to say:

Enter the list address here.
Something like:   [e-mail]

but the text gets broken down into:

Enter the list address
here.
Something like:   WineLovers-L@cellar.
wine.com

Which looks really ugly.
How do I force the line breaks that I want?
How do I change the size of the balloon?
I looked in InsideMac and there is something about "alternate rectangle"
but Resorceer does not same to be able to edit that field.

Help ?!?

Thanks

Michele

- --------------------------------------------------------------------
Michele Fuortes, MD/PhD
Cornell University Medical College
E-mail: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Resorcerer)
Date: 27 Dec 1995 00:34:52 -0500
Organization: America Online, Inc. (1-800-827-6364)

Michele -

>How do I force the line breaks that I want?
>How do I change the size of the balloon?
>I looked in InsideMac and there is something about "alternate rectangle"
>but Resorceer does not same to be able to edit that field.

Resorcerer lets you edit every field in any balloon help resource.  In any
case, you don't want to use any alternate rectangle field, and there's a
better solution.

When your message record(s) use 'TEXT' resources, or strings of various
kinds, the Help Manager chooses the balloon size and aspect ratio on its
own, and you don't have any control over the shape or choices of
word-breaks, etc.

However, if you use a 'PICT' message record, the Help Manager always sizes
the balloon according to the dimensions of the 'PICT'.  Unfortunately,
most 'PICT's are screen dumps that use a whole lot of space, and if you
are only trying to display text balloons, this quickly gets out of hand.

Resorcerer has a solution for all of this in that you can use the
'TEXT'/'styl' editor to enter the text of a message (including setting any
typefaces and colors), and then choose the command in the Text Menu that
creates a text-only 'PICT' resource that will display the same text in a
'PICT' that has the same size as the Text Editor's editing area.  This
'PICT' is not a screen dump, but instead is a recording of just the text,
font, and color information.  You can then use this picture in a 'PICT'
help message record.

The only possible downside to doing this is that you don't want to use any
wild fonts that might not be on your user's machine, since the 'PICT'
records the font name to use, but not the actual pixels of the text being
drawn.

Resorcerer has several balloon help messages that are quite large (see the
balloon for the Color Icon Editor's Lasso Tool) and these are presented as
text-only 'PICT's, which take up very little extra room over a standard
'TEXT' resource.

Hope this helps.

Doug McKenna
Mathemaesthetics, Inc.
Developers of Resorcerer
[phone]

---------------------------

>From [e-mail] (Owen Hartnett)
Subject: Need to unlock MF Temp Memory?
Date: Fri, 22 Dec 1995 21:06:04 GMT
Organization: Harlequin, Inc.

Think Reference says that when using MF Temp Memory, you need to unlock it
between WNE calls. Is there any reason for doing this other than making
the free Multifinder heap more compactable?

To restate: Is there any *mandatory* reason the MF Temp memory needs to be
unlocked over WNE calls?

-Owen

+++++++++++++++++++++++++++

>From [e-mail] (Stefan Kurth)
Date: Sat, 23 Dec 1995 02:43:07 +0100
Organization: none

Owen Hartnett <[e-mail]> wrote:

> To restate: Is there any *mandatory* reason the MF Temp memory needs to be
> unlocked over WNE calls?

NIM:Memory requires it, in a very clear language:

    "You must never lock temporary memory across calls to GetNextEvent
     or WaitNextEvent."  (p. 2-10)

That should be reason enough.


--
Stefan Kurth
Berlin, Germany

+++++++++++++++++++++++++++

>From [e-mail] (Phil Shapiro)
Date: Sat, 23 Dec 1995 14:06:26 -0500
Organization: Symantec Corp.

In article <[e-mail]>,
[e-mail] (Stefan Kurth) wrote:

| Owen Hartnett <[e-mail]> wrote:
|
| > To restate: Is there any *mandatory* reason the MF Temp memory needs to be
| > unlocked over WNE calls?
|
| NIM:Memory requires it, in a very clear language:
|
|     "You must never lock temporary memory across calls to GetNextEvent
|      or WaitNextEvent."  (p. 2-10)
|
| That should be reason enough.

The reason NIM:Memory says this is because a locked handle can fragment
the Process Manager's heap, eg if the user switches out your app and
launches another while you've got your handle locked down.

In other words the OS won't crash if you do this, but it will probably not
be able to make efficient use of memory.

   -phil
--
Phil Shapiro                                 Senior Software Engineer
Development Tools Group                          Symantec Corporation
                     [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Tue, 26 Dec 1995 21:21:23 -0800
Organization: Internet for the Olympic Peninsula

In article <phils-2312951406270001@155.64.60.59>,
[e-mail] (Phil Shapiro) wrote:

>The reason NIM:Memory says this is because a locked handle can fragment
>the Process Manager's heap, eg if the user switches out your app and
>launches another while you've got your handle locked down.
>
>In other words the OS won't crash if you do this, but it will probably not
>be able to make efficient use of memory.

And if the locked block happens to be at the very bottom of the Process
Manager heap, thus preventing expansion of the System heap when the System
wants it expanded, you can run into one of the silly bits of code in the
System which behave poorly (read:  crash) when they need more System heap
and can't get it.

   --John

--
  "This item is not available because it cannot be removed."
John W. Baxter    Port Ludlow, WA     [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Phil Shapiro)
Date: Wed, 27 Dec 1995 12:07:54 -0500
Organization: Symantec Corp.

In article <[e-mail]>,
[e-mail] (John W. Baxter) wrote:

| In article <phils-2312951406270001@155.64.60.59>,
| [e-mail] (Phil Shapiro) wrote:
|
| >The reason NIM:Memory says this is because a locked handle can fragment
| >the Process Manager's heap, eg if the user switches out your app and
| >launches another while you've got your handle locked down.
| >
| >In other words the OS won't crash if you do this, but it will probably not
| >be able to make efficient use of memory.
|
| And if the locked block happens to be at the very bottom of the Process
| Manager heap, thus preventing expansion of the System heap when the System
| wants it expanded, you can run into one of the silly bits of code in the
| System which behave poorly (read:  crash) when they need more System heap
| and can't get it.

Well, I have a lot of experience with code that locks handles on the MF
temp heap across WNE calls and I've never seen a crash due to it -- I use
HLockHi to prevent the problem you describe. (Now, do you want to trust
someone who admits that they have experience with code like this? :)

   -phil
--
Phil Shapiro                                 Senior Software Engineer
Development Tools Group                          Symantec Corporation
                     [e-mail]

---------------------------

>From [e-mail] (Sean McDowell)
Subject: New Mac games programming web site!
Date: Thu, 28 Dec 1995 01:49:58 GMT
Organization: University of Waterloo

In order to make myself semi-useful to the world at large, I have started
a games programming site, <A HREF =
"http://www.undergrad.math.uwaterloo.ca/~smmcdowe/Bitstop.html">Mac Games
Programmers' Bitstop</A>.

I am no HTML wizard, so things are pretty straightforward.

Do stop by and have a look. Any contributions of links or suggestions are
welcome!

Sean
[e-mail]

---------------------------

>From [e-mail] (MuffinHead)
Subject: Script Editor Apple Events
Date: Mon, 18 Dec 1995 19:37:28 -0600
Organization: Armpit Studios VIII

   Does anyone know the event (code, parms, etc) that is sent to Script
Editor so it will select the range of text after getting an error in an
applet? I haven't been able to locate documentation for this, nor could I
figure it out by spying on events.

MuffinHead
Drummer, Mac geek                                  Armpit Studios VIII
http://www.winternet.com/~muff/                    Plymouth, MN
______________________________________________________________________
So I guess the moral here is: Never throw a used fuel pump from a
Russian rocket missile into Possum Lake.
  --Red Green

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Mon, 25 Dec 1995 07:17:31 GMT
Organization: Apple Computer

In article <[e-mail]>,
[e-mail] (MuffinHead) wrote:

>   Does anyone know the event (code, parms, etc) that is sent to Script
>Editor so it will select the range of text after getting an error in an
>applet? I haven't been able to locate documentation for this, nor could I
>figure it out by spying on events.

It's an optional parameter on the odoc event.  It corresponds to the
kOSAErrorRange which you get from OSAScriptError call.  It's the same
record you get from that call.  Just add it to the odoc event with the
same keyword you used to get it from OSAScriptError.

As an aside, you need to decompile the script if the error range comes
back as 0,0 and then get the error range again since AppleScript doesn't
know the range until it has seen the text.

Jon

--
What are YOU doing to oppose the Microsoft juggernaut?

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 26 Dec 1995 03:04:13 GMT
Organization: University of Michigan

MuffinHead, [e-mail] writes:
 >    Does anyone know the event (code, parms, etc) that is sent to Script
 > Editor so it will select the range of text after getting an error in an
 > applet? I haven't been able to locate documentation for this, nor could I
 > figure it out by spying on events.

Check out the reference for OSAScriptError() in NIM:Interapp. Comm, pg 10-37.
You need the "Error Range" selector, but to extract the data you will need to
explicitly coerce the returned descriptor into an AERecord.

Matt

* * * * * * * * * * * * * * * * * * * * * * * * * * ======================
*  Reality: Matt Slot                             *  Time is an illusion.
*  E-Mail:  mailto:[e-mail]             *  Lunchtime doubly so.
*  Web:     http://www.sils.umich.edu/~fprefect/  *     -- Douglas Adams
* * * * * * * * * * * * * * * * * * * * * * * * * * ======================

---------------------------

>From [e-mail] (Jay Farrell)
Subject: [ANN] Mops 2.7 Macintosh Programming Environment
Date: Sun, 24 Dec 1995 04:08:49 -0500
Organization: Jayfar's Web


Mops 2.7 is Michael Hore's public-domain development system for the
Macintosh. A powerful and robust hybrid of Forth and Smalltalk, Mops has
extensive OOP capabilities including multiple inheritance, and a class
library supporting the Macintosh interface.  Includes all source code and
Doug Hoffman's Quick Edit program.  Mops has been updated to incorporate
the latest Apple Universal Headers.

Mops is a fabulous language for getting down to the bare metal when you
want to, though fairly high level if you build on the supplied classes.
It also includes 68k & PPC assemblers for writing your more time-critcal
methods.

Mops does not yet produce PPC native code (except from the aformentioned
PPC assembler) -- we expect it will be within the first half of the new
year.

You can test code interactively in the interpreter as you develop, and
then generate your optimized standalone app.  Mops and Mops apps will run
on even a Classic or SE, as well as on the newer Macs.

For the F.A.Q., the manual and tutorial, Mops itself, and other Mops
resources, see The Mops Page:

      <URL:http://www.netaxs.com/~jayfar/mops.html>

You'll also find Mops in the /dev directory at info-mac, with the manual
in /dev/info

Cheers,
Jayfar

   ////~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~////
  ////   The Mops Page    <URL:http://www.netaxs.com/~jayfar/mops.html>    ////
 ////~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~////
////   Mops is Mike Hore's freeware Forth/Smalltalk hybrid for Macintosh ////
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Jay Farrell     [e-mail]        Philadelphia, Pennsylvania, USA

---------------------------

End of C.S.M.P. Digest
**********************


Attachment converted: Stuff:GrafSys C lib/int.cpt (PACT/CPCT) (00001F87)